We’ve been pretty amazed at the response to Chris’s series on the Case against Google Maps with IBM Cognos BI.
That post has generated a lot of traffic and some feedback, both pro and contra.
To everyone who has responded -- thanks for the input, whether you agree or not. It’s always good to see other points of view.
The comment that caught me most by surprise (posted in response to Part 3 of the series) was that the post is “corporate group think that is killing geospatial in the enterprise”.
I have to think there may be a lot of people who will react in this way. I mean, Google Maps and Google Earth are so cool, right? And so powerful. I would say yes to both of those assertions. Useful too.
But the point is (and it’s the main one) is Google Maps the best option for integration with IBM Cognos BI? Google has lots of great uses, but not so much as an enterprise GIS capability. Why is that? It comes down to meeting requirements in the most cost-effective way, with the best bang for the buck. That’s not corporate group speak. It’s helping people get to their objectives with the lowest costs, in the fastest time, with the most suitable tools.
The comment to which I refer in fact affirms this, if you read it closely -- something about "faster to develop and more responsive to use".
And with sincere and due respect, nothing is killing GIS in the enterprise, especially not us. It’s alive and well, and thriving. We’re doing everything we can to proliferate it, and our recent webinar on this very topic set a new record for registrants. Google has been a huge help in this regard, actually, because people are now accustomed to viewing just about everything in a map.
There may be cases where a very specific geospatial BI requirement means delving into a mapping API to do weird and wonderful things. If so, have at it with whatever API makes sense for you and provides access to enterprise-scale GIS. But for the vast majority of applications we see, IBM Cognos BI users are looking for points on a map and thematic shading of aggregated measures based on region, tied together with supporting BI data (like charts with timelines, costs, trends, resources, and so on). Why delve into custom coding for that when you don’t have to? Why use an API-driven approach that means every new report requirement means more coding? Why not use tools that do that for you, that integrate completely with the BI tools you already use, and that leverage report authoring skills already in place?
But we love a good debate. Feel free to chime in.
- dk