Large public security organization
A geospatial system that runs in the client's data center, without vendor access
We built a geospatial awareness system that runs as a VM inside the client's own data center, where we have no access. Each release is a tested, versioned VM, and everything the client may need to change, from roles to map boundaries, sits with its own admins.
Government, Legal & DefenseOn premise geospatial web applicationBuilt from zero
The challenge
The system holds highly sensitive data and had to run inside the client's own data center, where we would never log in, with support only through the client's authorized IT staff.
What we did
We moved every likely change into the client's hands, from roles to KMZ map boundaries and import scripts, and shipped each release as a VM built from our main branches and tested before handover.
The outcome
The client received the system as a series of versioned VM releases, and its admins change users, roles, groups and map boundaries without waiting for a release from us.
- Hosting
- On premise VM in the client's own data center
- Vendor access
- None, support goes through the client's IT staff
- Releases
- Versioned VMs, regression tested first
- Client owned settings
- Users, roles, groups, lists, map boundaries
The starting point
The system gives leaders of a large public security organization one map of alerts, incidents and responses across many teams and regions, with role based visibility and approvals. It holds highly sensitive operational data.
What had to change
Everything had to run inside the client's own data center, and we would never log in to it. Any change that needed us on the server would mean waiting for a new release through the client's IT staff.
What could not break
- We never log in to the hosting environment
- Fixes and releases reach the server only through the client's authorized IT staff
- The original plan assumed an air gapped network
- Historical records from several regions had to load into the same system as new entries
- Every release is tested as the VM the client will install
The calls we made
We designed for a system we would hand over and never touch, so anything the client might need to change had to be something its own admins could do.
- 01
Boundaries as admin uploads
Map boundary sets are KMZ files that admins upload in the admin panel, with exactly one active set on the maps and features they can redraw and label.
Ruled outBoundaries built into the code, which would need a release for every change.
- 02
Administration inside the product
Users, roles, permissions, groups, the organization hierarchy and lists of values are all managed by the client's admins in the product, so none of them waits for a release from us.
Ruled outConfiguration that only a developer with server access could change.
- 03
Import scripts the client can run
We analyzed missing locations and mapping conflicts in the historical spreadsheets, wrote repeatable import scripts and handed them to the client contact.
Ruled outA one off data load that only we could run.
- 04
Ship the VM, not the code
Each release is a versioned VM built from the latest main branches of the frontend and backend, following a documented build path, after full regression in our own environments.
Ruled outHanding over source code for the client's staff to build and configure on site.
How the system fits together
What we built
Versioned VM releases
The full application packaged as a VM from the latest main branches, with regression cycles before each build and VM testing with our DevOps team before it went to the client.
Boundary management
KMZ boundary import in the admin panel, one active set on the maps at a time, and features that can be redrawn and labeled, shipped in its own tested VM release.
Admin and access control
Users, roles, permissions, groups, the organization hierarchy and lists of values, all managed by the client's own admins in the admin panel.
Historical data import
Repeatable import scripts for historical records from several regions' spreadsheets, written after an analysis of missing locations and mapping conflicts, and handed to the client contact.
Training material
A user guide for access control and boundary management, a walkthrough of the KMZ feature, and walkthrough videos for each core module.
How it works
Build and test
Features are built and tested in our separate dev and QA environments.
Regression
Full regression cycles run before the VM is created.
Package
The release is built as a versioned VM from the main branches and tested with our DevOps team.
Install
The client's IT staff take the VM from a shared folder and install it in their own data center.
Run
The client's admins manage users, roles, groups, lists of values and map boundaries themselves.
What changed
The client received the system as a series of versioned VM releases for its own data center, with the boundary feature following in its own release once testing was done. Its admins change users, roles, groups and map boundaries without a release from us, and testing on the VM caught upload and approval issues while they could still be fixed.
- KMZ upload and approval hierarchy issues
- Caught before handover
Under the hood
- Datics role
- Product built by Datics
- Deployment
- A VM on premise in the client's data center; we have no access to the hosting environment and debug remotely through the client's IT staff.
- Release path
- VMs built from the latest main branches through a documented build process, versioned, and handed over through a folder the client shares.
- Map data
- Google Maps base layers, GeoJSON feeds and admin managed KMZ boundaries, with one active set at a time.
- Security
- JWT authentication, role and group based data filtering, and sensitive fields limited to designated roles.
Apps and APIs
Also in the stack
How it shipped
Built in sprints
The whole system was built in sprints in our own environments, with working builds shown to the client and its feedback folded into the next sprint.
A repeatable VM build
Our DevOps team worked out and documented how to turn the latest code into a VM image, so every release follows the same path.
Client owned configuration
KMZ boundary management, admin managed roles, groups and lists of values, a user guide and walkthrough videos for each core module.
Regression, then versioned releases
Full regression cycles before each VM, testing on the VM itself, then releases placed in a folder the client shares with us, with fixes shipped as the next version.
Working builds on a rhythm
The client saw working builds regularly, and each round of feedback went into the next sprint.
Support through the client's IT
Fixes and releases reach production only through the client's authorized IT staff, who coordinate remote debugging with us.
Documented for self service
We wrote the user guide and recorded module walkthroughs so the client's team could run the system without us.
What this unlocked
Open items such as a custom report builder and a notifications module are kept for later, with post deployment support proposed through the client's IT staff.
Related work
Have a product with the same kind of constraints?
Tell us what already exists and what you want it to do. We will tell you what it takes.