If the NSW Police Service had had at its disposal in 1992 the resources available to it today, there is a good chance backpacker murderer Ivan Milat could have been apprehended months earlier than he was.
Milat began his killing spree in 1989, but was not arrested until May 1994. This followed a gruelling 20-month investigation - an investigation sparked by the discovery of the remains of two British backpackers, missing for five months, in a lonely pine forest in the NSW Southern Highlands in September 1992. Eventually seven bodies were found. Back then, seven bodies meant seven discrete investigations, each with its own team of investigators. Seven discrete investigations led to seven silos of information, each entirely quarantined from the others. In a sense, it was that quarantining which protected Milat from scrutiny for far too long. Oh, how far database development technology has come!
If drawing silos together was a massively complex task in the early 1990s, today it has become much easier, thanks to the intranet-based email@example.com Investigation Management system, rolled out earlier this year. And in building firstname.lastname@example.org the NSW Police Service has shown that CIOs wrestling with ways to Web-enable legacy systems, or to make the transition from old mainframe-based screen systems, will do much better with a well-described road map and a clear understanding of what they want to achieve. The system has also proven the value of adhering to a set of key architectural principles, which have helped make it the powerful investigative tool that it is today.
The email@example.com system provides fully scalable investigation management to help define hierarchies of management and information flow while maximising information sharing. It should mean that no key investigation will ever again be hampered by falling into separate silos under different investigators. "With the system that we have now you may well start with seven separate investigations," says Pedro Harris, general manager information technology, NSW Police. "But once you get the idea that it is, in fact, one investigation, you can bring all the data from all of those investigations together into one investigation."
If the backpacker murder investigators had had firstname.lastname@example.org on hand they could have put to better use vital information from a former Royal Navy sailor, Paul Thomas "Bunny" Onions, about an encounter with an armed man on the Hume Highway near Berrima. As a result, Milat might well have become a serious suspect much sooner. Instead, police discovered the information from Onions by sheer chance, and much later than the earliest point at which it would have been useful. "If we had had email@example.com we could have picked this up a lot earlier, because we would have trawled the database looking at instances involving backpackers and hitchhikers," Harris says.
Because firstname.lastname@example.org is built on an object-relational database, police can capture all the information pertaining to an investigation - from text-based statements and witness reports to photographs and video clips - in a single data store. That, Harris says, makes it a relatively straightforward technical problem to bring data together so as to identify related information more readily. "Putting it into one single data store makes it a relatively straightforward technical problem to bring that data together now - to say this information is related to that information and it's all part of the one job."
And that is just as well, because a serial murder investigation demands massive resources. For instance, by late December 1993, detectives involved in the backpacker murders were digging through more than a million pieces of information from the public. They were checking 50,000 registered owners of Ruger .22 rifles and investigating potential suspects ranging from known sex offenders to wife batterers. Coordinating all that effort makes for a massive human resourcing and tasking problem. That is another area where email@example.com comes into its own.
Produced and supported by Oakton Computing, firstname.lastname@example.org Investigation Management is proving a technologically advanced solution to the problem of freeing investigators for the task of investigation. The system has been sponsored by Assistant Commissioner Clive Small, Commander Crime Agencies, and the commander in charge of the backpacker email@example.com has a thin-client, Web-based architecture that minimises configuration control issues on the desktop to help reduce in-house support costs. As a result, firstname.lastname@example.org simplifies team management, task management, coordination and information, leaving investigators free to do the real work of investigation. It also provides full electronic capture of all collected information, a system-wide entity-link web and "plug-in" support for analysis and charting tools to support intelligence analysis. In doing so it simplifies the task of comparing statements and looking for trends and consistencies.
Most systems doing similar jobs tend to focus on complex task of associating bits of information in clipaways and net diagrams, in a bid to identify patterns human investigators have missed. Oakton Computing general manager John Quinn says email@example.com does the exact opposite. "It deals with the 90 per cent of the problem rather than the 10 per cent of the problem. The 90 per cent of the problem is allocating roles to people, allocating people with roles to teams, allocating tasks to the people within the teams, and then capturing the product that they gather as a result of the tasks that they do."
Quinn says the system, designed and implemented with grass-roots input from front-line members of the NSW Police Service, addresses the problems and issues of modern-day operational policing.
COPS: Part II
firstname.lastname@example.org was built under stage two of COPS, the NSW Police Department Computerised Operational Policing System (COPS), where every police activity has its beginning. Underlying COPS is a core system for handling five distinct types of objects: people, locations, vehicles, property and organisation. Each of these can be used in various ways. For example, a person might be a victim, a witness, or an offender.
Harris says the biggest design problem for stage one was getting the right data model so that the system would be flexible enough to let objects be used across all NSW Police's different business activities. That was vital, since stage two provides for a broad range of specific business applications - including investigation management, case management and charge management - which rely on that core system.
Harris says email@example.com was built rapidly using a Rapid Application Development (RAD) approach. Work was speeded by having expert police investigators work closely with the development team in a prototype approach. But Harris says it was the Informix DataBlade technology that proved most useful in keeping the design phase short. "A DataBlade is, in a sense, just another piece of accelerant software that does a specific thing. For example, if we want a text search capability, we can either write that or we can buy a Blade that fits into Informix that provides that. Now we've bought the Excalibur DataBlade that does text searching for us, and there's also a spatial DataBlade for map information, and a security DataBlade that looks at how we handle access to function and data fields. So we don't have to build that, we bought it in the database itself."
One reason for the unusual speed was the need to get firstname.lastname@example.org up and running well before the Sydney Olympic Games later this year. That led to some trade-offs when it came to integrating the application with legacy systems.
As the first significant operational Web-enabled system to be built by the NSW Police Service, email@example.com prompted the service to some hard decisions about whether it was better to interface or integrate with legacy systems. Harris says by choosing integration then, he has left himself open to some very hard decisions now about whether to continue building in the old Adabas/Natural legacy environment, or whether to do the conversion to a single platform a lot sooner than the Service had originally planned.
"I think the way I'm looking at it right now is loosely coupling, but closely integrating. It is a trade-off, basically, because the business needs the application; and we can get tied up, in the sense of making it so tightly integrated that it may not provide any further business benefit, although it may provide some technology benefits in support. So there is a bit of a trade-off there," Harris says. "If I hadn't had those time constraints, I would possibly have spent some more time on more tightly integrating them and thinking through those integration issues in a bit more depth."
Another change is that with so many expert users on the teams in NSW Police Service's design process, the service is now approaching its tendering environment somewhat differently, looking for ways to inject far more fluidity into the tendering process. "We've learned we need more fluidity in our tendering and development process, because there are a lot of new ideas and new initiatives that spring up when you put the expert users and the developers together. These may not have been even contemplated when that original tender was put up," Harris says.
"So one of the lessons I'm learning - and I think this is a developing process for me - is about the need to introduce process fluidity without increasing the order of magnitude on cost. How do I harness that in the design phase without over-engineering and failing to deliver on the business benefits immediately?
"Building systems today means breaking away from the traditional approach and trying to find a hybrid: of delivering the business system, and also making sure that we've got the best in stage one without sacrificing functionality," Harris says.
It's All in the Architecture
Long before the firstname.lastname@example.org Investigations Management System was built, Pedro Harris' team had decided that the NSW Police Service mainframe was entirely the wrong platform on which to build the system. "Instead, we decided we should rather wait at least until the organisation's network was modernised sufficiently to handle the information types that you would expect of an investigation," the NSW Police general manager, information technology, says.
Harris says the NSW Police Service made six key architecture decisions long before it developed email@example.com. This eventually made deploying the system much easier than it otherwise might have been.
Modernised Star Network. The modernised frame relay star network began its life as a pure SNA-based network, but can now support multiple protocols. TCP/IP runs across the same network infrastructure as SNA traffic, and the network can expand or contract according to requirements.
Standardised Desktop. Information comes in to firstname.lastname@example.org from a range of common desktop tools, in the interests of flexibility. That means that in order to support a particular format for statements, for instance, the IT department can build macro forms and provide them to police officers out in the various locations to fill in. The forms are then sent into email@example.com and captured in its database.
If the required format then changes - say because of a new legal requirement - it is a simple matter to change the form at the desktop without having to make any alterations to the application. "It gives us tremendous flexibility to cater for changing circumstances, and those things do change," Harris says. "Another example is that briefs of evidence at the other end of the process now are built using the common tools. So instead of the application having all the context of the data, the application sources the core data and uses those common tools to be able to manipulate it."
Data Model Information Management Plan. The Data Model Information Management Plan is the foundation on which all of the applications under COPS are built. By specifying that similar objects are dealt with in similar ways in different applications, the data model allows consistency and makes it easier to integrate the applications across that corporate data model.
Database of Choice. NSW Police uses Adabas as its legacy operational system, but chose Informix for its operational system. "Relational is very good for transaction processing," Harris says. "Multidimensional lends itself more to analytical processing, which we tend to do quite a lot of, in trawling through data and comparing information.
Harris says the business requirement always determines NSW Police's choice of database. For example, the service uses SAP on Oracle for its administration systems, because SAP has the market share and thus SAP is the environment that best positions NSW Police to outsource administration should it choose to do so at a later date. "However, for our operational system we made the decision that we would use Informix for emerging and new applications, and we will continue on Adabas for the legacy part," Harris says. "So we were choosing the database that supported the best business application and having made that choice we then built in that environment."
Presentation. The Web browser is the key avenue to all NSW Police systems. "The way we navigate today is through our intranet, so from the intranet you go to COPS or from the intranet you can go to firstname.lastname@example.org and from the intranet you can get to our knowledge servers to access legislation and policy and stuff like that," Harris says. "Previously you would log onto an application of COPS or you would log onto an application of Investigations. So on the presentation layer we said the browser is now the window to all our applications, and within the browser itself we would run the emulation for that application."
Harris says the decision had given the police maximum leverage, in that once an application is learned investigators can easily reuse these in the next environment.
Application. NSW Police seldom outsources its application build. Rather it relies on composite teams, comprising an application development partner and an internal team; chooses its partners carefully, and makes sure a significant amount of cross-skilling takes place. "That means once the project is wrapped up, we've got sufficient skills internally to continue with it," Harris says.
And while NSW Police might build applications in a number of different languages, it limits the development tools it chooses to use. "So in the application in the business area of, say, admin support, our main application will be SAP, so we'll use ABAP as the basis of the language in that area, so we'll have skills in that basis. In the operational world we'll have Natural for the legacy systems, but also for the emerging Web environment which we use.
"And while we've got maybe 20 different development tools we could have used, we've limited that specifically in the environment in which we now work to a combination of different tools. So we're limiting our subset to what we believe will be the best application tools to build the best application in the database of choice that supports that business application."