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.
Acredito que essa nova versão será muito poderosa, principalmente pelas parcerias que a ESRI veio desenvolvendo no decorrer do tempo, enquanto o 9.3 estava fazendo sucesso…
http://bit.ly/6ybATm
Lá vamos nós de novo ter que nos acostumar com o novo skin do nosso querido ArcGIS.
Um abraço a todos.
Bill:
You are hiding great thoughts behind this nearly impossible to read Darth Vader design theme. Prey do your readers a service and lighten up. FTR, I copy and paste your posts into a word processor to read them.
It’s my winter theme. 🙂 It sort of matches how I feel during winter.
Feedback noted. Look for something more accessible shortly. Thanks!
basically, I also don’t like this theme: it remembers me a porn site 😀 😀 😀
Paolo,
What about the new, brighter one?
Bill
ok, but I was joking, also the other one was fine for me 😉
COM-based ArcGIS is here to stay, unfortunately. Like it or not, ESRI is in the “platform” business. Sure they have some nice desktop and server tools, but the real lock-in is the thousands of tools other people and companies have created on top of their “platform” i.e. ArcObjects. Bill and Abe may be willing to abandon / rewrite their tools if ESRI clean slated their platform to a contemporary technology, but we’re the exception. ESRI would orphan so much of their customer base in this scenario that Jack would have to start selling off his yachts. This is the exact same predicament in which MS Office and Visual Studio find themselves.
The best we can hope for – and as you eluded – is the .Net layer (or your pet layer) is so far abstracted away from the COM junk that you can’t tell. A complete API rewrite will never happen … at least as long as COM is still alive.
I tend to agree with you. Quite frankly, a platform shift away from COM is my personal standard for ArcGIS right now. Otherwise, they might as well keep going up through 9.9999 IMHO.
ESRI has precedent for doing such major shifts. Ask any business partner that had built commercial Avenue extensions how they felt about the shift to ArcGIS. AML developers might have a thing or two to say as well.
Nonetheless, the install base is much larger now (and worth more money) so that may keep us here for a long time.
Really, anything written in native C++ is at the most risk. If you’ve written an app in .Net, then impacts of swapping .Net-wrapped COM objects for native .Net objects can be managed pretty well.
With a little planning and forethought, I think it’s do-able. But it’s not my money. 🙂
hi Bill/Abe
I suspect a new .net framework would still require a full rewrite for anyone currently using the .Net Interop assemblies. They closely match the existing COM interfaces and if (*if*) they do rewrite AO, it will get a full makeover (I’m thinking something similar to the AGX API, just lots more features). Conceptually, your code flow may stay the same but it would be a rewrite.
as it is, the new extension/addin framework will be a will cause enough headaches for existing developers
I’m not sure why they changed the name. It seems odd to jump horses so far into the race (we’re rapidly approaching B2).
My guesses:
1) They’ve made a breakthrough in some new technology that was slated for 10.0 and waiting two more years before release would be foolish
2) They want to make it seem like they have a new technology breakthrough and will spend 10.1 and 10.2 actually implementing it
3) The release schedule is slipping, rebranding as a Major release buys time and implementation sympathy
4) They already ditched side-by-side, maybe they’re ditching reverse compatibility (Save As). Need a new major version to drop that bomb
5) Google factor – They need to recapture the geospatial message. GeoDesign and a 10.0 release help.
6) –or – It really does have enough new features to warrant the version. Could be, not sure I see that, but it could be
cheers all
brian
Brian,
Always great to hear from you. I am not expecting an AO rewrite (but we can dream). All of your points are very true and any such transition would be painful enough to give pause. The transition from Avenue/AML/MapObjects/et al was certainly painful enough.
BTW, all the possible scenarios you mention have crossed my mind over the last few days.
Bill
I have seen some demos that show that Desktop now has a dockable, Visual-Studio-like UI. I think users will have more options for managing screen real estate and such.
New look and feel!?! Looks like ERDAS/ESRI are doing the whole Chicken/Egg thing again…And it also looks like they finally included some DS Mapbook-type functionality in to core ArcGIS. That’s great but I wonder how the GeoPDF folks feel about that one? I’d be interested to see if it *does* pump out “Geospatially Aware” PDF documents.