Spillman Flex CAD — five mission-critical integrations, one vertically integrated platform
Public-safety dispatch isn't one workflow — it's a dozen mission-critical integrations stitched into a single console. Across four years I shipped five of them on the Motorola Spillman Flex CAD: alarms (ASAP2PSAP), radios (Red Thread Line), telephony (ICC, US-patented), responder IoT alerting, and dispatcher scheduling. Same pattern reused — air-gap-friendly bridge, abstract action surface, real-time fan-out, embedded keyboard-first UI — produced the only end-to-end vertically integrated NG911 stack in the US, now serving 12% of all 911 traffic.
- Mission-critical integrations
- 5
- Alarm-to-dispatch speedup
- 60×
- Radio status SLA met
- <3s
- of US 911 calls
- 12%
Problem
A 911 dispatcher console isn’t one application — it’s a dozen separate mission-critical systems sharing a desk: alarm-monitoring feeds, radio status, the telephony switch, IoT sensor alerts, scheduling, GIS, the records system, and on. Each had its own protocol, its own vendor, and frequently its own physical PC. The dispatcher was the integration layer — manually translating between systems while a caller was on the line.
The bet: stop building integrations one-off and treat the integration surface itself as the product. One repeatable pattern, applied across alarms, radios, telephony, IoT, and scheduling, shipped on the same Spillman Flex CAD platform.
Approach
The shape that recurs across every integration: a WSS or protocol bridge that crosses the air-gap without violating it; an abstract action surface (six verbs, not a custom UI per system); parallel fan-out of database lookups on event arrival; and a keyboard-first embedded strip in the CAD incident screen so the dispatcher never leaves the keyboard. Same skeleton, different skin per integration.
- Vision: re-imagine CAD as a map-centric command center.
The dispatcher operates a city; the interface should treat them like a commander, not a clerk. Game-based, map-centric CAD became the north-star artifact — every integration had to earn its place on that surface or it didn’t ship.
- Scope: map the full integration surface end-to-end.
Five integration categories, each with its own protocol and vendor: alarms (industry-standard ASAP), radios (LMR), telephony (ECW/VESTA), responder IoT (sensor-driven alerts), scheduling (internal). Mapped them all on one canvas before scoping any one of them — so reusable infrastructure wouldn’t get scoped per project.
- Pattern reuse over per-project invention.
The WSS air-gap bridge invented for telephony became the default approach for radio and IoT. The PIDF-LO address resolution invented for ASAP became the location standard for the rest. Whenever an integration tried to invent its own bridge, the answer was: use the pattern.
- Lean on industry standards where they exist.
ASAP2PSAP rode on top of an existing standard from the alarm-monitoring industry — 17 protocol iterations to make the standard actually work, but the standard was the starting point, not a green-field design. Same approach for LMR on the radio side.
- Iterative, agency-by-agency rollout.
Soft launches in single counties, then states. Real-world failures fed each next iteration. The deployment playbook from ASAP2PSAP later got reused for VoIP-911 and SMS-911 rollouts.
The first integration is product work. The second is platform work. By the third, you either have a pattern that compounds — or you have five different unmaintainable bridges and a roadmap that runs out of people.
What shipped
- Alarms — ASAP2PSAP.
Alarm-monitoring → 911 dispatch time collapsed from 3 minutes to 3 seconds (60× speedup). 17 protocol iterations on the ASAP standard, PIDF-LO unified address resolution, three states live during COVID.
- Radios — Red Thread Line.
Real-time radio status integration for 3,000+ active LMR units. Initial deployment caused a self-inflicted DDoS — payloads stripped to
unitID, statusIDonly, hitting the 3-second processing barrier required by the network. Now broadly used across New York. - Telephony — ICC (US patent).
Twenty-two dispatcher commands collapsed to one. WSS air-gap bridge with six-verb API, parallel database fan-out on call accept. Patented. Deep dive →
- Responder Alert / IoT.
BPMN-modeled IoT alerting flow into the CAD incident screen — sensor events from the field surface to the dispatcher in the same control strip as the rest, no separate console.
- DRR — Dispatcher Resource Roster.
Hackathon prototype to shipping product. ~80% of shifts are unchanged week-to-week — the tool auto-schedules those and lets dispatch leadership focus on the 20% that actually need judgement. Reused existing CAD commands so adoption was friction-free.
The radio integration was the hardest of the five. The stress-tested prototype was clean in the lab and fell over in production: 3,000 LMR units multiplied by status-events-per-incident multiplied by incidents-per-shift exceeded the network’s 3-second hard discard window. Diagnosis came from log analysis, not architecture review — and the fix was deletion, not addition. Strip the payload to two fields, drop everything else, route on special codes. The lesson generalised: most integration failures at scale aren’t bugs, they’re extra fields.
Responder Alert / IoT extended the same pattern to a domain that didn’t even have a dispatcher in the loop yet. The BPMN model wasn’t academic — every node mapped to a real handler in the integration, and every edge mapped to a real timing constraint. By the time the BPMN was reviewed and signed off, the integration was largely already specified.
DRR is the integration that proves the pattern: a non-dispatch workflow (scheduling), built by a hackathon team in two days, deployed using the same CAD command surface as everything else, adopted without retraining. When the integration surface is the platform, even adjacent workflows ship through it.
Outcome
Reach
12% of all US 911 calls
The combined integration platform now sits behind roughly 240M 911 calls per year, the only end-to-end vertically integrated NG911 stack on the US market.
Speed
60× alarms · sub-3s radio · sub-second CAD
Each integration measurably faster than the legacy workflow it replaced. The cumulative time saved across all five integrations is the difference between a stopped emergency and a finished one, multiplied across the country.
Defensibility
US patent + only vertically integrated stack
The telephony bridge is patented. The combined integration surface has no equivalent on the market — competitors ship one or two of these integrations, not all five on a single platform.
Business
Most profitable year in 4 decades
The product line posted its strongest financial year in 40+ years on the back of this integration platform. Customer base grew 50%+ in five years; pattern reuse compounded the per-integration delivery cost downward each cycle.
What I’d do differently
- Document the integration pattern as a public template, not just a repeated practice. The WSS air-gap bridge, the six-verb action surface, and the PIDF-LO-style address pattern were all known internally by the third integration — but they were never written down as a template that prospective customers and partners could read. A published platform spec would have shortened sales cycles meaningfully.
- Build cross-integration telemetry from day one. We knew how each integration performed in isolation, but not how five of them interleaved on a real dispatcher console under peak load. The cumulative cognitive load and the failure modes across integrations are where the next decade of 911 product work lives.
- Sell the platform, not the chapters. Each integration was sold as its own line item in the customer conversation. Buyers cared more about "everything talks to your CAD" than which specific protocol bridge was inside any given chapter — we under-told the platform story and let the chapter-level pricing absorb the message.
Related work
