Apps Deconstructed

Last week, I discussed what enterprise architecture for deploying GEOINT apps might look like (read the Apps and Enterprise Architectures blog).  This week, I want to revisit that topic with a focus on the components that make up a sophisticated GEOINT app.  I’m defining a GEOINT app as a web-based or mobile application used to perform geospatial data visualization, processing, or analysis.  The figure below is my attempt to show the components of an app and how they might be represented in an enterprise architecture.

 

 

In this figure, app users are shown on the left, and the developers who participate in app development are shown along the bottom.  The middleware, web services, and data that an app uses are shown in the central part of the diagram and are hosted in the Cloud.  The point of this diagram is to show that an app is not just one piece of software.  The software that runs on the device or the web client interface and is displayed in the browser are pieces of a larger, interconnected system.  Multiple software components make up most sophisticated apps.

Let’s take App B from the diagram as an example.  Assume that this is a line-of-sight app that the user has downloaded from the App Store to his mobile device. When this app runs, it expects to connect through the internet (or the cloud) to app-specific middleware that will access image, map, and analytic services to produce the desired results.  The line-of-sight app initially presents a map where the user selects the area of interest.  The middleware calls an image service to locate relevant imagery in the correct format and then calls a line-of-sight analytic service.  Results are returned to the app interface, or client, running on the mobile device.  If you follow the lines for Apps C and D, you’ll see that they are similarly constructed.  I included App A to illustrate the case where an app connects directly to a web service without any middleware.

The various components that make up the app may not be written by the same developer or organization.  Some organizations may just provide services that are consumed by a number of apps, such as a map service.  Others may leverage those services and create the clients and middleware in order to construct robust applications.  These various components may not be on the same server, or even part of the same network.  The use of standards is key to the success of these distributed applications.

The services do the bulk of the ‘heavy lifting’ in this type of app.  Well written services can be used in a variety of applications, both interactive and automated.  A developer could create a set of services that can be deployed in multiple ways to meet a wide variety of user needs.  Notice in the diagram that each service is a component in multiple apps.  In my line-of-sight example, the analytic service that supports the line of sight analysis in the interactive app could also be used as part of an automated process to generate a line-of-sight result on all images as they are ingested.

I’m excited about the possibilities of this model where a single service meets many needs through a variety of applications.  I’m also curious as to how these services will be managed from source code control through deployment into enterprise environments.