The announcement that ArcGIS 9.4 is being re-christened as 10.0 leaves me feeling somewhat bemused. I have seen the new version of Desktop and it is nice and will finally update the current Office-97-feeling UI. The list of changes coming in 10.0 (published so far) is impressive but I haven’t seen any discussion of the changes coming to the ArcGIS architecture, which is of greater interest to me as a developer and integrator. Given the past history of ArcGIS, calling this release 10.0, in my mind, implies a significant architectural shift. ArcGIS 8 was a clear departure from the previous releases of ARC/INFO. Indeed, it not only came with a new version but introduced the name “ArcGIS.”
ArcGIS 9 represented a less-radical, but significant architectural update. By restructuring the underlying ArcObjects components of ArcGIS, ESRI enabled the introduction of ArcGIS Server and ArcGIS Engine and began to unify their desktop, web and mobile offerings. ArcGIS 8 would not have been able to support this.
Quite frankly, I think the current ArcGIS architecture has just about run its course. I think it is time to recognize that desktop, web and mobile applications are each different and need to be built differently. The current reliance on a common pool of ArcObjects, while not necessarily a bad thing for the desktop platform, is a hindrance for ArcGIS Server. To be specific, I am talking about COM here.
ArcGIS Server would benefit greatly from breaking its dependency on COM. I would not complain if I never had to do this kind of stuff anymore. This would, of course, mean replacing the capability for extending ArcGIS Server using ArcObjects with a similar capability. It would also mean choosing what to replace it with: .Net?…Java?…ROR?…something else? I think recent efforts with the REST API and its client technologies (JSAPI, Flex API, Silverlight API) speak to a way ahead. I can now pick a native approach and build ArcGIS solutions with less COM than ever before and ArcGIS Server itself is abstracted from the client code enough that replacing the technology that drives it can be relatively transparent. My hope is that these APIs continue to evolve and become more robust and are, perhaps, augmented by a server-side API to enable the development of advanced custom tools without the use of COM.
While ArcGIS Server is far from perfect, it does provide one of the better (quasi)REST APIs available and a consistent way to expose geo-processing and analysis in web applications. I think an official realization that Server is different and a commitment to re-engineer it top to bottom will benefit it in the long run. So the announcement of 10.0 now begs the question “What is the roadmap for the 10.x series?” I haven’t seen anything yet that indicates 10.0 will introduce such changes but, perhaps, it could be setting the stage for them. ArcGIS 9.0 was released in May 2004. By the time of the scheduled release of 10.0, we will have been working with 9.x for six years. The 8.x series lasted about three and a half years. Given that we could be looking at a few years of 10.x, I’d be interested in knowing more about the underpinnings of 10.x and plans for the future. Could make the DevSummit and FedUC interesting this year.