I’ve been holding back on this post trying to figure out what has changed since I last thought I understood ArcGIS 9.2 licensing. David Maguire goes into a pretty detailed post about ArcGIS Server 9.2’s Business Model.
Basically what we’ve though about the cost of licensing the ADF on another server is less than I thought it would be. Bascially:
As in the case of SDE, when the Web ADF and the SOM/SOC are on the same machine only a single license is required, but if the Web ADF is on its own machine (for scalability purposes) then this machine will also need a license. We will allow a single socket license (50% of the two socket license) to be used for additional Web Tier deployments.
What this means if you wish to deploy the WebADF on another server, you’ll only have to pony up 50% of the price of the license. I’m not sure how this works to be honest. Lets say you have a license for ArcGIS Server Advance Enterprise, in theory you’d have to pay half the cost of that license to put the ADF on another server. But what if the application you wish to put on that other server is no more complicated than an ArcIMS site. Can you only license ArcIMS functionality for that additional site (saving thousands) or do you have to license the full blown AGS Advanced Enterprise.
Steve posts some thoughts on his blog as well and comes to the conclusion that the cost even at 50% is probably too high. I’d have to probably agree with him unless you are really getting the functionality out of the site. Don’t forget though:
Existing ESRI users will be able to continue using their existing software on their existing licensed configuration for no additional cost. Customers on maintenance will receive an appropriate edition of ArcGIS Server 9.2 which they can run on the existing licensed hardware configuration for no additional software or maintenance fees.
This whole change in licensing has really worried me since I first heard about it. BUT between the whitepaper last week and now David’s post, I’m feeling pretty good about my understanding. As a consultant and developer, that is really all I need to move forward (well a scope of work would be nice too). David’s blog post is exactly the kind of communication we’ve been asking for from ESRI.