Apps and Enterprise Architectures

In the world of Geospatial Intelligence (GEOINT), there has been a lot of talk lately about Apps, App Stores, and even App Malls.  There is also discussion of who will create, manage and deploy Apps, as well as how App developers will get compensated and how end users will access the Apps.  I’m wondering what Apps might look like from a Software or System Engineer’s perspective.

Let’s define a GEOINT App as a web-based or mobile application used to perform geospatial data visualization, processing or analysis. My colleague Pat Collins and I wrote a couple of posts last year about the anatomy of Apps (see “Apps – What’s in a name?” and “Anatomy of an App…or ‘Just the Tip of the Iceberg’”). In these posts, we talked about what makes up an App and how there’s often more to an App than meets the eye.  When I’m talking about Apps here, I’m talking about the kind of Apps that rely on data and services outside of the interface a user sees.  Pat and I used a bank app and a coffee shop finder as examples.  While these appear quite simple, they rely on a number of services, such as map services and GPS, that are not available on the device or system where the App is running. Many GEOINT Apps will fall into this category as well.

The ability to access and consume web-based data and services has become a new standard by which software is measured. Many organizations are actively developing enterprise-wide geospatial software and services, because these solutions are much easier to manage than multiple desktop instances. This type of architecture also creates efficiencies in data, processing, and workflow sharing.  Due to their distributed nature, these solutions are well-suited for cloud deployment.

Figure 1 shows a notional Enterprise Architecture that might be used to deploy GEOINT apps. The front end clients deliver the user experience or user interface.  This is often what a user thinks of as the App. These clients can be simple, with button-based interfaces that allow the user to get answers to questions like “Where can I land this helicopter?” without understanding the data and processing required to build a product with the answer.  Clients can also provide robust user interfaces that allow users to perform complex searches on available data and have explicit control over every parameter setting on geo-processing functions.

 

 

The middleware brokers the communication between the client and the services running on the server. In order to keep clients simple and light weight, the middleware may hold the business logic that determines the appropriate source data and parameters for a geo-processing function.  Some think of the middleware as the glue that ties an application together and keeps it running properly.  Middleware isn’t always required, as some client applications or functions can skip the middleware and connect directly to the web services running on the server.

The web services that run on the server are the real workhorses behind complex Apps.  These services can include processing, image services, data services, map services, GPS services, and more.  They don’t all need to run on the same server to work together and they typically do not.  While this seems rather complex, the complexity is hidden from the end user, which is part of what makes Apps appear so deceptively simple.

Standards are critical to the success of these services-based architectures.  REST and HTTP are standards that define how the various components communicate with one another. Standards such as WCS and WMS define how data is requested and made available across the components.

A services-based enterprise architecture is ideal for development of a suite of Apps that can put GEOINT in the hands of a wide range of users, from field-deployed soldiers and first responders, to sophisticated image analysts working inside the Beltway.  A key benefit of the enterprise architecture is the ability to share resources, such as data and processing services. Imagine a scenario where a small set of geo-processing services serves a number of different users via a variety of client interfaces.  Some client interfaces could be very simple, while others are quite complex depending on the individual user’s needs.  The users experience different Apps, but the same services are driving those apps.  This is the part of the App discussion that I haven’t seen widely addressed. I’m working on some system diagrams that support a single service to many clients model.  I’ll be back with that next week.  In the meantime, let me know what aspects of the App Enterprise Architecture you are most interested in or would like to explore further.