Five elements of a justice information systems modernization strategy

Explore strategies for modernizing justice information systems to enhance efficiency, collaboration and data integrity across agencies.

There is top-down pressure to decrease operating costs and improve efficiencies of justice systems, objectives that can be achieved with newer technologies like the cloud and AI, but those systems must first be modernized before these technologies can be leveraged. Justice, by its very nature, is a connected enterprise, with 100s of federal, state and local agencies exchanging data and running cross-agency workflows. This requires modern systems integration and messaging technologies. Legacy technologies cannot deliver efficient cross-agency collaboration; moreover, these technologies often involve a dwindling resource pool and expensive infrastructure support contracts that can be hard to exit. Critical software and hardware infrastructure may be nearing obsolescence or already obsolete, raising the risk of operational disruptions and security breaches. Perhaps most importantly, systems modernization is required to protect against reputational risk and meet accountability requirements. Justice agencies are subject to scrutiny by the media and the public and must answer to their federal and state overseers. There is little tolerance for broken down systems that allow people and cases to fall through the cracks.

One thing that becomes clear very quickly as we work on justice systems modernization projects is that a “factory” approach is simply not possible. The variance in operating models and technology landscapes is such that each instance of the problem must be individually considered — agency by agency, department by department. Given that there can be no single justice systems modernization methodology, this paper presents five broad strategic elements that can reduce risks and accelerate outcomes, once these have been tailored to the agency’s circumstances.

2. Legacy coexistence

The key challenge in most modernization projects is operational continuity and avoidance of business disruption — sustained access to critical business processes and data even as the agency goes through the modernization journey. A particular challenge is the continuity of interagency interfaces that cannot be allowed to break as an agency modernizes its systems. The usual response is phased modernization — bite off smaller chunks of the problem — but that is more easily said than done given the monolithic structure of legacy justice systems. There are many internalized dependencies that are difficult to unravel and often there is no separation between business rules and application code.

We recommend that agencies leverage the interoperability platform to enable legacy systems coexistence during the modernization journey. The interoperability platform not only connects the new modules together but also connects them to legacy components, thereby allowing the agency to modernize at its own pace. A viable approach is to establish the platform as the API orchestrator across new and old systems early in the process and then gradually replace old systems at the back. The API orchestrator can also be used to distribute workloads selectively to new and old systems, thus enabling the “strangler pattern.” Workloads can be moved off the legacy system in a phased way — first adult caseloads and then juvenile, say, or vice versa — such that eventually the old system is strangled and the new system takes over.

When planning for legacy system coexistence, it’s important to identify the bodies of algorithmic complexity early in the process and bring the appropriate architectural approach to bear. Usually, algorithmic complexity — complex business rules across widespread data points — is more difficult to handle than architectural complexity. Architecture either works or “fails fast,” whereas it may take many years to detect the incorrect implementation of a business rule — maybe because the business scenario is infrequent or the defect is buried too deep.

Legacy components containing complex business rules can be refactored to provide an externalized service interface, and façade APIs on the interoperability platform can then be used to encapsulate these components. If the modern infrastructure supports the legacy component’s runtime, a viable approach is to containerize the component and run it adjacent to the interoperability platform. While we discourage brute force use of code conversion tools, as that often ends up producing the same monolithic target state the agency wants to move away from, surgical application of such tools can be useful. A viable approach is to use AI-aided tools to extract business rules from application code into a decision model and notation (DMN) that can then be executed by a rules engine. While these approaches entail architectural complexity, it helps avoid elongated testing cycles and failures down the line.

3. In-place data access

A specific aspect of the operational continuity problem is the continuity of access to data. Unlike financial or manufacturing systems, criminal justice systems must preserve access to data even if it’s from 50 years ago. Such access encompasses generations of data representation formats and access protocols. Mandated data separations, such as between adult and juvenile data, need to be maintained throughout. Conventional data conversion methods fall short when handling this kind of complexity. Converting decades worth of records, many of which are interdependent, incomplete or stored in outdated formats, is the most common failure point in justice systems modernization.

There is a paradox here: The older data, greater the effort to transform and cleanse, but lesser the likelihood that the data will be used within a new transaction. As such, much of the data conversion cost — at least in theory — is a waste. We recommend that the agency leverage the interoperability platform to minimize the data conversion footprint and avoid this paradox. The platform’s entity resolution capability can be used to locate records in connected legacy systems, and platform APIs can encapsulate legacy-read services to offer a unified view data across new and old systems. Only in the rare event that an old record needs to be edited and incorporated into a new transaction should it be converted into the new database. While the architectural complexity here is significant, the approach can be very effective if implemented correctly.