The Right to Remain Mobile: The Toronto Police Department's eCops Application Uses Data Mining and Wireless Technology to Unshackle Its Information Infrastructure

Bad boys, bad boys ... whatcha gonna do? Whatcha gonna do when they come for you? If any of the bad boys live in Toronto, they had better find a new line of work. In October 1999, The Toronto Police Department, the fifth largest municipal law enforcement agency in North America, started work on eCops (Enterprise Case and Occurrence Processing System) - the first of its kind crime reporting application. IBM's infrastructure software, including DB2, DB2 Universal Database (UDB) Satellite edition, WebSphere Application Server and MQSeries, will be used as the foundation. The department expects to increase productivity and reduce technology costs by at least 50 percent as a result.

The Toronto Police Department consists of 5,000 officers and 2,000 civilians.The eCops application will support more than 7,000 shift workers, so at any given time, there may be upwards of 2,000 concurrent users when the system is fully operational. However, not all workers will have access to the system. For example, HR personnel would have no reason to access the police records information system. For future growth, plans are in place to have the technology scale past 7,000 simultaneous users.

DB2 will also become the new foundation for the organization's current Oracle-based PeopleSoft human resource and payroll applications. Those applications are expected to be on the new system in the next three to six months.

eCops will provide officers with an electronic method of processing missing person reports, crime cases and occurrences, warrants and other criminal information. Some of the most compelling reasons for building a data warehouse as the basis for the eCops system are to analyze trends and patterns in criminal activity, enable quicker verdicts and discoveries and, ultimately, to find the "bad boys" faster. Data mining technology and extensive mapping/geographical coding will also create a more efficient use of resources. Wireless access via mobile laptops and the ability to cross-reference Toronto Police data with international agencies will also be implemented.

The Toronto police department decided on the IBM solution for three main reasons:

• The integrated suite of products and an application development environment that fit their needs and requirements. They felt comfortable with the basic componentry in the WebSphere strategy - from MQ to SecureWay on the mobile workstations, to network DB2 on the back-end database.

• DB2's demonstrated scalability.

• The significantly lower cost differential on the database acquisition.

After the pilot mode, eCops will go into production by the end of 2001, or the beginning of next year. eCops is estimated to save the organization more than four million dollars through a reduction in clerical staff, with a return on investment (ROI) expected in four years. The Toronto Police wanted an aggressive deployment schedule, while also managing their risk, so the cost of the program is being spread out over three fiscal years.

The mobile workstations, the eCops application and the mobile data network were purchased for a total of $18.6 million. That figure includes all the mobile workstations for the scout cars, modems, mobile data network and the development of the application itself.

The eCops systems will use IBM's DB2 and DB2 UDB on the client and the server, WebSphere application server, NQ Series 5.1, Visual H for Java for the development work and the SecureWay Wireless Gateway for handling the mobiles, which will be implemented via TCP/IP over a radio network. The selected workstations are NT and the servers are AIX RS/6000.

"With DB2, we have many built-in functions for performing rolling averages and aggregation functions, as well as an entire statistical analysis library, that makes it very simple to perform 'what if' analysis," says Jeff Jones, Senior Program Manager at IBM. "IBM has invested a lot of development effort to integrate mining, warehousing and analysis capabilities right into the engine. This means that customers get what they need, with less code to run and fewer layers of software to get in the way of their applications."

"By choosing DB2 to build a data warehouse, the Toronto Police will be able to store criminal and arrest information and to provide access to that information from anywhere. The DB2 UDB Satellite edition is an extension of DB2 that supports mobile end users," comments Jones. "While many other police departments can already view information from their squad cars, the new eCops application will also allow Toronto police officers to create or edit reports and transmit them from any location."

"We view IBM's DB2/UDB products as an 'up and comer,' that is quietly gaining marketshare; a lot of that has to do with price performance," says Mark Shainman, Senior Research Analyst at the Meta Group. "In many instances, DB2 is a third of the cost of the Oracle product."

Shainman feels that the limitation of the IBM solution really comes down to the applications available for DB2. "However, IBM realizes this is a critical issue, so they have a specific team in place right now that is out there garnishing ISV support for more applications."

Chris Pentleton is playing the role of architect and designer for the Toronto Police eCops solution. He has worked with the Toronto Police, and other police agencies for 14 years, implementing everything from network architecture to network servers. "The decision to use DB2 was primarily a financial one. We weren't really worried about features and functions," explains Pentleton. "When it came right down to it, the price differential between Oracle and IBM was a no-brainer. In one case, we didn't have the budget and in the other case, we did."

From a functional point of view, Pentleton liked that DB2 was fairly well-integrated with their application server line. "It certainly made us feel a lot more comfortable using DB2 and WebSphere application server," he says.

In Pentleton's opinion, Oracle is trying to be all things to all people. "Where Oracle is trying to build-in file systems and other kinds of functionality, it just adds to the complexity and size of the database," he notes. "I like that DB2 is just a database - it does database functions, and it does them well."

Like any large-scale implementation project, the Toronto Police Department had its own share of problems. Pentleton called them "typical bugs."

"We expected the application to work one way, but, in reality, it worked in a slightly different way," he says. "There was an actual bug in the WebSphere software or in DB2 - where maybe something worked on NT, but not on AIX. However, it was nothing that caused us to derail our project."

"The software, for the most part, is reasonably stable; although we've experienced some minor problems. We have a good partnership with IBM and the labs in particular, so we've been able to work through the problems - and continue to do so."

Because the software they're using is still pretty new, it's a lot of complex software trying to work together. A moderate amount of delays were spent trying to figure out what the Toronto Police Department and IBM meant by a particular way of doing things: How does the Java transaction work, how does the transaction roll-back actually work in the product, as opposed to how it's presented in the specification. Those issues have caused Pentleton to adjust the schedule to change the internal design, or gear some of the development in a slightly different way, once the problems were better understood.

Pentleton notes, "Like any project, we tended to underestimate how long it will take to understand the project, then implement it. Once we have a design plan in place, we have to get the developers to understand it, then implement it according to the project plan, instead of the way they want to do it."

Despite some initial delays, Pentleton feels that the project is still relatively on schedule. "We've been able to incorporate the necessary changes, because we did know to some degree that it was an incremental process, and we scheduled that time up front. However, I think we may have underestimated the time required for testing by about 20 percent." He recommends that other companies involved in such a project include a wide margin of real-life testing scenarios.

Another issue of concern is the size of the development team. Pentleton is currently working with 25 developers, but says it took about six months to "really get things moving nicely and have the team talking." As the team adds new members, Pentleton says it's extremely important to keep the lines of communication open between everyone: developers, management and users.

What helped the project immensely was to make sure the users were involved at the beginning of the project. Pentleton went beyond having users participate in just the requirements phase by deeply involving them in the technical design and the architecture of the system, as well. Now that users understand the technology well enough, they know what the system can do and cannot do - so they won't ask the developers for features that are really hard, impossible or just plain silly to implement.

"In simple terms, the Toronto Police need to identify situations earlier, address issues faster and use a more focused application of police resources to solve problems and minimize the impact on our communities," says Mike Farrar, Toronto Police Inspector. "It's the difference between feeling a bit of wind and a hurricane hitting. We want to be in there sooner and get the job done. It's much easier to address the small issues, rather than waiting before it gets so significant that we have to over-resource the problem."

eCops will be replacing three legacy franchise systems on the Toronto Police mainframe: the occurrence database, the arrest database and the client server database, which houses their case management/case separation software. From a systems integration standpoint, they wanted to incorporate those three basic standalone applications and improve the process into one entity.

The Toronto Police Department wanted to get crime information data and records entered into the system at source, or as close to source as possible, to eliminate any duplicate data entry requirements. "We're trying to replace a partially paper-driven/mainframe approach, with a completely software approach," explains Farrar.

The Toronto Police also wanted to deploy an Internet architecture to further efforts of agency-to-agency cooperation and leverage knowledge found on the Internet. What Farrar is trying to avoid are the problems involved in completely updating a legacy mainframe system to operate in an Internet-based world, as they share information with other government agencies and police partners, and, possibly, out to the community they are paid to serve. "We're trying to have a little bit of forward thinking on this, by embracing technology that doesn't require a significant reengineering of all the gears under the covers," he notes.

When the system is complete, officers will have a larger width and breadth of information for conducting investigations more effectively. More importantly, when information (such as occurrence reporting or arrest reporting) is collected, it will appear on the system faster.

Once the crime data is entered in the backend database, the Toronto Police will use an integrated system of business intelligence, crime analysis and crime mapping tools to examine trends and hot spots from the local, operational and strategic levels.

Although the core module is all 100 percent new development work, eCops also consists of an object-oriented framework that will reuse key components and take advantage of plug-in modules, to avoid a constant new application environment.

For example, Pentleton has obtained a Java-based, name-search engine from a company in Ottawa, a business intelligence tool and a mapping application. He is currently looking for a Java-based geographical encoder. "We're using the plug-in modules, rather than building everything within the application suite itself. We've found it's a more cost-effective approach," says Farrar.

For future developments, Farrar is looking at a combination of in-sourcing and outsourcing, depending on the case. The Toronto Police is currently training some of their senior staff to handle the development need; later, it will be a combination of contract staff and permanent staff that will be responsible for new enhancements.

Before eCops, officers went through a significant learning process on an earlier client-server application that replaced typewriters. In the process, the Toronto Police Department learned a lot about how the officers think, their likes and dislikes of the application and how to navigate in the program. With that knowledge, eCops is being designed with the input and guidance of police officers to carefully replicate their daily needs and requirements.

"Because eCops is based on how officers think and work, we're avoiding a significant amount of what I call technical sizzle," says Farrar. "This new application intuitively reflects the process from taking a radio call, filing an occurrence, making an arrest, preparing the case and depositing that case before our client attorneys for prosecution."

Officers can get information about current investigations by using a variety of sophisticated search tools to query as many of the Toronto Police databases as needed. The immediate advantage is getting more data to the officers about people they're speaking to, any files that would be available on the arrested parties and any previous history related to their case.

"It's like everything else," comments Farrar. "We know it won't be a panacea when eCops arrives this year, but we're constantly collating user requirements as we go along. We're filtering user requests and sorting them into modules to make the best work environment for the officers."

Currently, officers may have to use four to six different systems, go through several different staff personnel and a lot of manual intervention to enter and update reports. When completed, the eCops system will allow officers to enter the information once - and that will be it. There will no longer be a need to have clerks enter the data into another system or synchronize the information within the overall police system.

"The eCops program will automate everything from A to Z as to what police do on a day-to-day basis. Right now, if an officer is on the street, or in a car, they have to come in to the station to create an occurrence or other kind of report," explains Pentleton. "Now, they'll be able to do that in the car. Obviously, that will save them a lot of time."

Farrar wants to ensure that police officers have more information about crime, occurrences and arrests at their fingertips in the mobile environment, so they can do more targeted, intelligent and focused investigations. This will make the officers' job considerably easier, and it will also give them more up-to-date information. The eCops system will help increase officer safety and allow the police department to serve the community better.

A number of other police agencies are in various forms of acquisition or development modes in Ontario and Canada. In Ontario, the Common Police Environment Group (a collection of police chiefs) is developing an information sharing strategy. Over the next several years, all involved police departments will be moving aggressively to share information. The first output of that group is a set of data standards that will allow data to be shared from an EDI perspective.

Currently, the Toronto Police Department is sharing information with their city partners, which will be enhanced with the completion of eCops. For example, in the city of Toronto, they share accident information with the Department of Public Works from a road design perspective. They have agreed that the best way to display this information is in a map-based context, so all the collected data will be geo-coded at source. Once the data is geo-coded and entered in the system, users have access to all the embedded history behind the address.

After this production release, the Toronto Police is planning on annual releases for the next three years. For example, in the next year or so (if funding arrives from the city), they plan to develop a comprehensive accident investigation and reporting module that will be deployed at the scene by police officers investigating accidents.

Also in the future, the Toronto Police plans to electronically file their case preparation materials with prosecutors, who could then link up and share their own data, such as dispositions, guilty pleas, bail, paroles, probations, etc. They are currently in discussions with a number of policing agencies to share information across organizational boundaries.

One of the reasons why the Toronto Police decided to invest in the IBM suite is the concept that, in the future, they want to have police officers equipped "anywhere, any time and with any device."

"The technology we've embraced with IBM is their concept - and we support that, because we would not have gone down that road if we knew they couldn't handle the architecture we need. We certainly didn't want to reengineer our architecture two years from now into a PDA-type of device," notes Farrar.

"We're looking at deploying a PDA-like device within the next two years, because not all police officers are in marked vehicles. Many officers work from horseback, bicycles, motorcycles or on foot. We want to find a way to get all police officers access to any type of information they need to get their job done and ensure safety for the community."