Geospatial Revolution

We were asked to look at the geospatial capability at a UK Government department. They relied upon maps to co-ordinate their work and it was clear from the start, this wasn’t going to be just another tech-refresh project

Look at the state of the geospatial service, to include:

• Infrastructure
• Software
• Data ingest, processing, storage
• Value stream
• Usage
• Support
• Data sourcing
• APIs
• Consuming apps

Using a series of stakeholder workshops, we dug into what the problems with the service were. It became apparent there were just too many problems it wasn’t worth trying to do any sort of in-place upgrades. This fully supported our position of performing a ground-up rebuild of the entire stack.

Starting with the business architecture, we built business functions that included customer relations, map data sourcing, reporting analytics, and a stable and well-defined API for consuming apps. We also tore it away from one particular app and made it a Product in its own right. This meant the new team supporting it could have a free-hand in developing the service and not be constrained by the needs of one app.

Next, we worked with the mapping vendor to design a suitable infrastructure, to fully lever the virtualisations capabilities of both compute and storage. As this was an on-premises service, we had to rely upon the client’s internal capabilities, but they had a good script-based virtualisation service, which we made full use of.

One of the main issues we had to overcome is the speed at which new maps were ingested, processed, and made available to users. We had to cut the several months to hours, if not minutes. Using the virtualisation available, we were able to take a chainsaw to the times. From first request to the map being made available was cut to just one hour.

The value stream could then be mapped out. New business capabilities were created purely for the new service. This puts it firmly in it’s own category and can scale as required for the entire organisation.

A new ‘customer services’ team was developed. These are dedicated people charged with being the friendly face of the service. They would be knowledgeable about what the service can do and what it offers, but are not charged with doing the processing. A whole new set of processes underpinned how they go about interfacing with the users.

In the back room, mapping engineers would take an agile approach to their work. Not only taking requests from the customer services team, but would keep up with patching the software, and updating existing maps. Requests would be evaluated and grouped for inclusion in a sprint. However, knowing how important the service is, it was possible to put in an urgent request should it be warranted. Standard requests were loaded into the call handling system, and output to a Kanban board. This allowed a morning stand-up to juggle the priority based on need. Using the Kanban took away the personality clashes and preferable treatment from the decision making. Patching and updates were done in sprints.

Users requesting a map would get it displayed in sub-second times. Accuracy was vastly improved and in line with on-line vendors such as Google or Bing.

Because the sourcing, ingest, and library had been redesigned, it was now possible for users to have access to a massive library. Indicators to show if the data had been processed or not, improved the reliability of requests.

Operational changes no longer effected the geospatial service. However, a broadening of the organisation’s coverage can now be easily handled.

Apps needing a map can now call upon a stable and well documented API. Enhanced security keeps out the unauthorised apps, while allowing authorised apps access to the resources they need