The Future of GIS is NOW

Microsoft

Back in 2017 I wrote an article about GIS and DevOps with a prediction that DevOps would become part of GIS. Since then that has happened at a technical level but there is a deeper implication that is just now starting to get explored. In this article I plan to delve more into this subject.

 

There is no doubt that many GIS groups/departments have started to move to the cloud, automate tasks in tools like Azure DevOps, and even started to question calling itself GIS. This is natural extension of the broader changes happening in IT but let’s take this to the next level. For example, many are starting to question calling themselves GIS professionals. Makes sense since GIS has tended to be part of a department or a group in IT. Being in a silo has meant that GIS takes specialization which has resulted in thick client desktop GIS app that only GIS experts could use. There has certainly existed the capability to publish geospatial data as a service but this has led to an approach to have to purchase large and expensive platforms which appears to provide a Swiss Army knife approach. Hundreds of tools embedded in one executable. This appears to be fine but as noted earlier, it leads to specialization, expensive thick clients, and implicitly limits agility. Say what? Let me quote the following from “A Seat At the Table” by Mark Schwartz:

 

“A product is a marketing concept—it is a set of capabilities grouped together to be saleable, an abstraction of features to which a price can be attached. In the old world, custom-developed applications were sort of like that, too: grouped sets of capabilities that were bound together as single executables. That is no longer the case.”

 

Also, “We have forced our users into talking about applications, as well—it is buried deeply in their way of thinking about IT. We give our systems cute names (I used to use cartoon character names—Casper, Nemo, etc.) or we teach users to refer to the product name (“then we look them up in Salesforce”). But why should users care about system names? Why should they even care what “application” or “system” a particular capability is found in?

 

Yet this idea of grouping capabilities into systems or products or applications persists. One reason for this is that we continue to think of the capabilities as something we have to make build-or-buy decisions on. If we can buy the capabilities, then they make up a product in the vendor’s eyes and an application to us, organized and bounded based on the vendor’s marketing approach. Or perhaps we talk about applications to satisfy the template zombies, who have organized their change control and security processes around applications. Or for the finance folks, who need to identify an asset and capitalize it. The one thing I’m sure of is that this notion of an application is getting farther and farther away from the actual architecture of our capabilities. A seated CIO presides over an architecture of resources, tiny building blocks that can be composed into different Lego-like constructions, and the units we used to deal in—applications or systems—are no longer meaningful. This is good: in the Agile world, we want to work in small units.”

 

And that is a key idea here. GIS isn’t dead and certainly isn’t dying. It is being diluted. It is being turned into small units that can be deployed in multiple scenarios which in return increases our organizational agility.

 

OK, but what about the GIS professional? That too is becoming diluted. Instead of being “T” shaped, meaning applying our expertise across multiple industries, the GIS professional needs to become more fork-shaped. In other words, multiple skillsets across multiple industries. Today that means knowing something about data science, geospatial, infrastructure, operations, etc. Of course, we all know this is happening but there is an insistence in keeping GIS as a role. Why?

 

One of the great movements in IT these days is DevOps. Much of what I have been discussing here is about DevOps but applies to other industries as well. It’s not just developer and operations, it’s also marketing, business, networking, computer graphics, and anything else the team needs. I’ve personally had to learn about all of these topics over the years.

 

If you look at the literature on GIS, even the father of GIS, Roger Tomlinson, and take a step back, it becomes clear that his book, Thinking About GIS, is clearly a waterfall approach. It is a linear series of steps. See Tomlinson’s “A 10-Stage GIS Planning Methodology.” Don’t get me wrong, this made sense just like waterfall software development did during its time. Things have changed.

 

These days instead of waterfall development we have Agile (with a big A). Also, instead of departments/groups sitting in a vertical siloes we have moved to horizontal value streams.

vsm.png

 

The result of this is a team or teams that support the value stream. The organization is now focusing on delivering business value in a continuous flow inside a cross-functional team. The organization has been tilted 90 degrees. There is no GIS professional, no specialized desktop app, just focusing on delivering value. This may certainly include geospatial but in a very specific sense using an API that is either purchased or developed in-house.

 

But what is value? I often hear people, especially in the GIS or Geospatial community still talk about requirements. Let’s refer to Mark Swartz again about this in “The Art of Business Value”:

 

“But how does leadership know what indicators of business value are the right ones to follow in order to achieve the desired business outcomes? My answer may be obvious by now. They don’t know. They have a hypothesis. They can use this hypothesis to influence natural selection in the organization and observe the results. As they see the results, they can alter their course. Natural selection eliminates leaders that do not deliver on shareholder expectations. Yes, we are ready now for my definition of business value: Business value is a hypothesis held by the organization’s leadership as to what will best accomplish the organization’s ultimate goals or desired outcomes.”

 

How do we know if including Geospatial will deliver value? We don’t. We have a hypothesis. Even the most obvious of technical capabilities is nothing more than a hypothesis, even if it is a tried and true. How do we do this? We use Hypothesis Driven Development. That’s how spatial statistics works but often this is not how it is done with other technical aspects of GIS. I often here people say “I have a requirement of X.” My responses, “What’s your hypothesis?”

 

Once again geospatial could be very well part of the value stream if the hypothesis is supported by evidence from the customer that value was delivered.

 

So, what is the future of GIS when it comes to technology? Once again it is diluted among a plethora of options for delivering value. In the past it has taken months to implement GIS before the first inkling of value is delivered. It took hiring a specialist. It took complex tools. None of this still holds. It’s now possible to go into Microsoft Azure and stand up a geospatial Platform-As-A-Service in a matter of minutes. It’s also possible for anyone to make maps with tools like Power BI. It’s possible to insert very specific APIs in the value stream for delivering value. The flexibility and capacity are at anyone’s fingertips. One can create a Logic Apps and do some geocoding by calling Azure Maps Geocoding REST APIs, or grab the current temperature outside and display that in a web app that supports a value stream, or determine the time it takes for someone to drive across a city or the time it takes to cross a city on a bus and tram, and so on. None of this takes specialization, it also didn’t take upfront cost, maintenance fees, etc. That doesn’t mean that specialization isn’t needed. Remember, you’re now fork-shaped so you get to keep your current knowledge but with other tines. In this team, you also learn about other fields and as a whole the team learns from each other which spurs creativity and that leads to innovation. 

 

In summary, it’s time for GIS as an isolated specialist field to come to an end but it’s also time for geospatial to explode and made available to everyone for the express purpose of delivering value to customers/citizens at the fastest possible means.

 

In future articles, I will delve deeper into these concepts so stay tuned.

 

1 Reply
Definitely recognizing the real world transformation of “GIS” highlighted in your article. It’s awesome for the users and the way spatial data will be embedded in everyday life. Accuracy and precision may take a hit along with traditions GIS professionals that have lost their hold on the cutting or bleeding edge of technology. It’s no longer enough to be the GIS guy or gal. You must be able to wear so many different hats and have subject matter expertise on top of all the spatial data and mathematics as well as the cloud environment and the security that keeps the data safe. In addition, it needs to look cool or users will lose interest.