Moving Change: The Importance of Small, Unsung Benefits

By Bert Granberg  |  June 1, 2017

This isn’t original but it's worth restating.

Maybe ‘change’ is so difficult because it’s so hard to know ‘when’ it’s the right time? That applies to life in general, but certainly to technology fields, like ours. In fact, there’s a whole body of study around the risk and benefit calculations made around technology, including my favorite description, the technology adoption life cycle. I am thinking about this today because I just had my first success with Esri’s latest GIS software product platform, ArcPro.

I am pretty sure that I am not considered an ‘Innovator’ or ‘Early Adopter’ for this change, especially considering how many GIS shops seem to bite instantly on the ‘you have to move now to version x.x’ hook without much thought. But maybe I am making the ‘Early Majority’ cut? It doesn’t really matter. It did, however, remind me of previous GIS software transitions that I’ve been involved in. And the common thread for those changes, surprisingly, was never a quest for the most hyped, flashy functionality.

Rather, it was that the new software presented some comparably dull, core functionality that just worked better for a project need that I had at the time. Simply put, it had the right tool for the job. Going back to the last century, for ArcView 3.0, it was the flexibility of the ’coincident geometry’ model (versus the strict shared geometry model of the node-arc coverage data format). The GUI environment was a huge plus, but that’s not what sold me. I needed ArcView’s ability to manipulate features as individual shapes, in order to efficiently finish a project.

For ArcSDE it was the potential to offer data-as-a-service to our Utah’s entire state GIS data collection. And not necessarily the versioned multi-user editing, which certainly presented needed functionality down the road. Btw, I’ll never forget my surprise when Learon Dalby asked incredulously after a ‘Utah Update’ presentation at NSGIC, “Wait. Are you saying that you allow anyone to make a read-only connection to your SDE database server? (we just assumed that everyone was doing that)

What drove my transition to ArcMap was the the ability to plot multiple maps (views) on a single page (layout) for the output of a DMV office location analysis project. It wasn’t the new support of CAD-like curve features and corresponding editing tools that were so prominently featured in the marketing and training materials.

For WMTS tiled map services, it wasn’t that OGC-based standards were somehow superior. It was that the economy and scalability needed to store and deliver base maps and licensed high-res imagery to hundreds of organizations (including non-Esri clients), that could only be found in a custom, cloud-based solution.

And, for ArcPro, it wasn’t the 3D capability, the ribbon interface, or the prospect of a transition to a future SaaS-styled, ‘named-user’ offering. Rather, my transition last week was driven by the need to get a very CPU and memory intensive python script working that was having a hard time in the old 32 bit, single threaded world. And, the Pair-Wise Intersect function, newly integrated into ArcPro seemed to work flawlessly across all 8 64 bit processors.

Whether it be software, IT platform, or just life in general, there comes a point when it’s time to make a change, to take a leap forward. And, in my experience, the ‘right time’ is often driven, not by a complex ROI calculation or the marketing/sales campaign, but instead by an opportunity for an important small scale win that sets the stage for a longer transition and sustained returns to come.