The Biggest Mistake Made By LE Technology Vendors: Part II

Posted on 13 March 2011 by

6


In Part I of this two-part post, I described some of the issues created by law enforcement technology vendors when they make technical decisions based on a desire to maintain the competitive sanctity of their software (again, if you’re a vendor who now hates me, use our Contact Us page and tell me about it).

I talked about Application Programming Interfaces, and how they are designed to help technology vendors interact with the products of other vendors, and I gave some examples of how this impacts workflow using license-plate reading technology products.

Now that I’ve given that technical example and lost 97% of my readers, let me lose 2% more by going further down into the weeds.

If you’re still here, that hair on the floor is mine: I pulled it out when I contemplated the issues of using the LPR-produced data to support an intelligence-led policing strategy: I can’t, without taking several time- or resource-consuming steps. Remember, I am talking about great – not just good – LPR systems from great companies.

Let’s look at what I would consider to be a highly basic intelligence scenario. I want to overlay on a map, and provide links to complete information about:

  • ShotSpotter** activations
  • Gang intelligence unit reports
  • Confidential Informant tips
  • Robbery reports
  • Parolee- and/or probationer lists
  • Convicted felon lists
  • Sex offender lists
  • Computer-aided dispatch notes
  • EMS call history
  • Etc, etc

Remember, I’m not picking on LPRs, this is a universal problem. Each data-set I just listed means extracting, exporting and importing information from within its own stove-pipe, its own walled-garden. So right there, before we’ve even got to my LPR example, we’ve moved beyond the perceived capacity of some large agencies, most mid-sized police agencies in the country, and most, if not all, small agencies in the United States.

It isn’t even that putting all this stuff would be that expensive or that difficult, technically – it’s that it’s so complex that agencies often assume that they just can’t do it.

[Why this is not true – that is, why it is not actually beyond their capacity and capabilities – will be the topic of several future blogposts and podcasts].

But let’s say that we did it and we’ve got this great map showing all that stuff. And now I see something that interests me. Maybe it was a confirmed ShotSpotter activation of multiple gunshots near a known convicted felon’s house, there was a call for service but officers couldn’t find anything but shell casings.

Now, remember – I got those LPRs on all my patrol cars, and I get hit with the brilliant idea – “Hey! which license plates did my patrol units see driving by at the time and area of the shooting?”

From an intelligence standpoint, as I say, this is a simple scenario: I want to know which license plates were seen in the area of the shooting around the time that the shooting took place. And then I want to compare the registered owners of those vehicles to the names on my lists of people I want to keep tabs on.

This would seem to be just basic common sense. But unless your agency has some fairly serious technical resources (people, processes and technology), this kind of view remains out of reach. The LPR I described requires an export, then an import. Another LPR – one deployed in many more agencies than the first one I mentioned – is better, and will allow you to run batch queries against the product’s internal databases to periodically download all the data from all your cars – or even some of the data from specific cars.

Harder Than It Needs To Be
Of course, if you do this once, it’s no big deal at all. But if you want to do it continually, then it’s a big pain in the ass, because you have to set up scripts to query, then export, then import, datasets from all your technology products. Anyone can do it once. Making tactical products provide strategic data is harder than it needs to be.

And with few exceptions, vendors of many of the products in the categories I just mentioned aren’t making it easier. Each of them has its own proprietary software that creates its own dashboards and command center. Each of these proprietary software packages offer reports (some a lot better than others). Most critically, each acts as if all the reporting you’ll need can be done based on only the data and information produced by that product.

This information therefore languishes in internal data stores, awaiting extraction, aggregation and correlation which, as I’ve just said, will never happen in most agencies.

In an upcoming episode of the Police Led Intelligence podcast, David and I will speak with two people doing something about this problem, and find out how they conceived their plan, how they funded it, and how it is working out.
________________________
* Often, the problem is that it’s too good, and officers hate the LPRs because it makes it like working in a rolling video arcade, what with all the beeping, blurping, sirening and other attention signals

**Disclosure: David and I have provided consulting services to ShotSpotter in an area unrelated to that discussed in this post. We have not been compensated by ShotSpotter to mention them publicly, nor in any way compensated nor provided any incentive to mention them in this blog.