Anatomy of an App…or “Just the Tip of the Iceberg”
Anonym
My bank likes it when I spend money. All the cash flowing in and out of my pockets translates into revenue for them. My bank also likes to help me spend my money, and has created a fancy ‘App’ to help me find ATMs and other banking resources near me no matter where I am at any given moment. What a novel idea…putting all the information right on my phone so I can easily find and spend my money at will…right? Wrong…while my bank may have an issue with me saying that spending my money is not a novel idea, I have an issue saying that all of that information is located right on my phone…and that’s where we come to the anatomy of an App.
Most people think that the Apps they download from the various App stores are small, self contained programs that provide all of the information and functionality directly from their phone. However, as soon as they move out of cellular and Wi-Fi range they quickly discover just how dependant these apps are on the services that they consume. I like to think of Apps as ‘interfaces’, much like a website on the internet. Without the databases, servers, networks, and data transfer protocols a website would simply be a pretty picture instead of an interface into a larger set of functionality and information.
A Set of Services Being Consumed by a Single App
In the case of my bank, the small file I download and install on my phone is simply an interface into a larger set of functionality and information. When I hit the ‘Find ATMs’ button, a GPS satellite reads my location using the embedded GPS chip in my phone. This location information is passed via the mobile network to the bank, and a proximity algorithm is run against a database of bank locations to select the nearest ATMs to my location. This information is then passed back to the phone, along with a feed from an Image Server which provides street maps as reference to my current location and the location of the nearest ATM. By clicking on the ATM in the map, a navigation routing algorithm is run to tell me the quickest way to get to the ATM and spend my money. The number of resources, from GPS satellites, mobile towers, servers, cables…etc, is enormous, and reaches far beyond the 1.87MB file that lives on my phone.
Multiple Apps Consuming Interoperable Services
So…what’s the point? The point is that we need a new way of thinking about Apps in the geospatial world. If GIS functionality is truly going to be ported to mobiles and tablets, we need to get past the point of downloading single interfaces for single slices of functionality (i.e. the company ‘A’ app, and the company ‘B’ app). We need to see interfaces that are able to consume ‘services’ from multiple vendors based on agreed-upon interoperability standards. Think of this as building a web browser instead of a website, allowing us to consume content from any number of businesses. The apps, or interfaces, instead of being vendor based, should be developed by the end-user to fit their specific need, with the ability to simply plug in to the larger set of functionality and information offered by cloud-based services. This puts the power of selection into the consumer’s hands, permitting them to access best-in-class services from multiple vendors to achieve their goals. Without this, functionality slices remain siloed and proprietary while the greater computing power of the cloud goes unexploited.
How does this relate to my money? Picture if I built an app/interface that instead of giving me the locations of my bank’s ATMs, it gave me the locations of all of the ATMs in the area, regardless of whether or not I was a member. I can still use their ATM right? It might cost a premium (ATM fee), but the cost might outweigh the distance I am from my bank’s closest ATM. Now, my bank may fight this idea initially, because it reduces the number of times I use their ATMs. However, it will eventually increase the number of times other bank’s customers use their ATMs , evening out and possibly even increasing their revenue over the long-term while providing the customer full control over the ‘services’ they consume.
What are your thoughts? Should GIS service providers focus on producing company-specific apps? Or should they focus on producing services for consumption in company-agnostic apps based on interoperability standards?