Spatial is Special, Spatial IT is Not

Part One – The Revenge of Moore’s Law

James Fee made an eloquent case for why he made the leap to WeoGeo. While I would like to claim the powers of a Jedi knight, I think the true motivation of his choice was the hard economic realities of the spatial IT business. As James mentioned, the pricing pressures in basic spatial IT integrations are increasing, which are resulting in a falling revenue flow for many integrators.

The future of Spatial IT as a technology sub-discipline.

I think this is happening for many reasons, but here is the major one. Spatial technology is becoming more robust and easier to use for repetitive business functions, i.e. building a slippery map that shows points-of-interests (POIs), lines, and polygons no longer requires a specialized GIS technology stack. Just getting an organization’s information on a map that can be viewed internally (intra-net) or externally (inter-net) used to pay a lot of bills. The problem is that it doesn’t anymore. To a large extent, we are the victims of our own success at demonstrating the power of spatially-enabled business content and services.

In addition, for other types of higher-order analysis, display, and spatial enterprise operations, you don’t need a proprietary specialized database any more (i.e. Oracle Spatial 11g ) as Microsoft SQL 2008 and others built geometry and geography natively into their applications. And of course there are the plethoras of open source options that allow you to avoid proprietary databases all together (e.g. PostGIS). With these databases, one does not need the spatial data engine abstraction layers (e.g. ESRI’s SDE, which might be why they quit selling it as a stand-alone product) to expose your organization’s spatial data to those that need it or other applications to consume it.  These spatially enabled databases also provide for some high-order geospatial analysis to be preformed without the need of desktop- or server-side products (like ArcGIS Desktop or Server), and in many cases without the need for GIS Professionals to run that analysis.

Part of this enhancement in the spatial technology stack could be laid at the doorstep of web advertising companies (e.g. Google), which are bringing billions of new dollars to bear on spatially enabling web services. Yet, I believe the trends were there before the release of Google Maps and Google Earth, as Oracle was putting spatial operators into their main release in version 9 in the early 2000’s.  Innovations in web mapping systems have been occurring at an ever-increasing rate; and we in the spatial field are just the latest recipients of the impacts of Moore’s Law on complex business services. As the spatial IT stack continues to evolve, one should expect the distinct separation between the “GeoWeb” and the “Web” to become increasingly fuzzy, with the distinction eventually becoming irrelevant.

What does that mean for the specialized services of the spatial technology integrator? The simple mapping stuff will be just part of the web programming stack, with little separation between web programming and spatial web programming. Spatial technology integrators will have to evolve to create more value from enterprise technology operations, where spatial is just one part of their enterprise project. This can be successfully done, and one only has to look at Dave Bouwman’s group DTSAgile (which is just kickin’ it) to see that it can be accomplished.

However, the competition will be fierce because the specialized spatial IT stack will evolve into the plain vanilla IT stack, with more competitors and easier-to-use technology. This will mean much lower margins per spatial project; and that is just the way of the economic “force”. In addition, I have been hearing stories of increased competition from specialized software vendors like ESRI for consulting revenues on increasingly smaller and smaller projects. This suggests that the integrators will be squeezed from multiple directions, setting up the potential for a shakeout for integrators in our industry.