The Biggest Mistake Made By LE Technology Vendors: Part I

Posted on 9 March 2011 by

1


There are some great technology products available for law enforcement agencies. Much of what is out there is pretty good tactically – locating gunshots and identifying license plates and other highly powerful law enforcement applications.

But as we here at PLI have and will continue to say, many also needlessly lack support for the strategic vision and operations of law enforcement agencies. This post is fairly long – about 1600 words – and gets into some weeds. So I’ve broken it up into two parts (Part II can be found here).

We hope that those who stick around until the end get some value from it and that it can serve as the basis of discussion.

[If you are a vendor in one of the product-spaces I mention, and you want to send hate mail, please use our Contact Us page (not the comment form below) and tell me you hate it. I’ll get the message and, if you like, allow you to post a rebuttal – provided, of course, that that your rebuttal is plainly written and doesn’t sound like it came from the desk of some marketing weasel.]

Here are some random and not altogether ground-shaking high-level observations about police and technology products:

  1. Police agencies are perennially underfunded;
  2. There are relatively few cops in the technology business, or who deeply understand technology;
  3. There are relatively few technologists who are police officers, or who deeply understand policing and the police culture;
  4. The business of selling technology to police is highly competitive (primarily due to 1 above);
  5. Those selling into the police technology market jealously guard their turf (primarily due to 1 and 4 above);

All these factors lead to a big problem: to protect their turf, to assure dominance and stave off competition, companies selling technology to police try to share as little as possible about their inner workings, lest competitors leap in.

And in a misguided manner, in practical terms, this has come to mean that few police technologies interface – that is to say, speak – with other police technologies.

The API
Don’t get me wrong, this is an issue in many industries. The trick is that vendors in other industries recognize that a certain level of interoperability is desirable. So vendors typically publish their application programming interface, or API. This is the roadmap that a vendor publishes that can be used by other technology vendors to interact with its product.

This is the lowest level of interoperability available: the vendor is not doing anything special with his product’s data, just making it possible for other products to interact with it. At a minimum, this would be to allow others to view (read) that product’s data, but in many cases, vendors make it possible to both view, and insert data (read and write) to the product.

This seems a little … I don’t know … groovy, but in fact it’s good business sense. It enables vendors of highly specialized products to inter-operate their product with others which may be more strategic, or more ubiquitous. It enables technology, marketing and go-to-market partnerships amongst complementary technologies, and in fact provides a streamlined path to acquisition of a smaller player by a larger one. At that point, the two products would be merged further, to sit somewhere on the continuum ranging from API-based interoperability to full integration.

It also allows the customer to do more with what he already has, and better leverage all his purchases. In these times of austerity and frugality, leveraging what you already have is a big selling point.

The Un-API
Simply put, many technologies bought by police function as islands unto themselves. This not only harms strategic use of the information these technologies produce, it actually works to ensure that there can be no strategic value to the information it produces.

By literally cutting off any information sharing (by refusing to allow interfaces, by making complex or difficult the process of inserting and extracting information to or from other products) many manufacturers assure that their product can only be deployed tactically.

From The Tactical…
To get specific, let’s take a look at a popular license-plate reading technology product. It’s an outstanding system and provides a huge amount of information that can be turned into intelligence if combined (aggregated) with other information. And your better intel shops do this. But when we see how the vendors make these agencies do that, it’s nothing short of stupid.

The product architects thought about one thing: reading license plates and comparing them to a list or lists of hot cars. It’s amazing at spotting and analyzing the license plates themselves – these kinds of products can do more than a thousand a minute, sometimes much more. It’s amazing at beeping or honking when it detects a match of a plate to a hot sheet*.

It starts being less good when you want to take a customized list of LPs – say, a list of tags you’ve made to inform you when an officer sees a known gang-member, or a known sex-offender, or a parolee, or a convicted violent felon. Interacting with the system requires creating your list, exporting it to a spreadsheet, saving the spreadsheet as a comma separated values file, then importing that file into the LPR system. There’s no direct way to simply send the text to the box, because it doesn’t truly integrate with any intelligence dashboard products that I know about.

Similarly, and much more problematic, to get data out of the box for the purposes of doing anything with them in the way of further analysis, you need to reverse the process: first, use the LPR’s proprietary software to search for something, then take your resultant dataset and export it (again, to a CSV-format document), then import it into something like Excel or whatever your intel platform is. With tens of thousands of plates registered in the software per shift, these are some pretty huge file exports.

Hell, on the system I am describing – and I’m discussing real, production systems, from respected technology vendors, deployed in police cars around the country right now –  the cop in the car can’t even cut-and-paste a license plate and associated information from the proprietary software into a Word document as part of his report writing. He’s got to ALT-TAB between the LPR software and his document and memorize the tag number and the data and type it manually into the document. Or export it to a PDF and then cut and past from there.

All this means that whenever you want to get information out of the proprietary software of the LPR into the proprietary software of whatever you’re using, you need to involve Microsoft Office or Adobe Acrobat. Neither of those products was designed for law enforcement, both are subject to malware attacks on a daily basis.

Is this the best we can do?


In Part II of this post, we will get further into the weeds to talk about how this proprietary and “walled-garden” approach hampers strategic use of information created or harvested by law enforcement products.