JIS Migration Plan

1. Executive Summary
2. Problem Statement
3. Background: The State of the Judicial Information System (JIS)
4. JIS Committee Strategy
5. Migration Plan Definition
6. Scope
7. Assumptions
8. Migration Risk Management
9. Migration Project Recommendations

Download a PDF version for Printing

Introduction

A goal of the JIS Migration Plan is to provide a common understanding of the processes and recommendations for supporting a strategic, enterprise-wide court information system in the state of Washington.

The plan contains some unfamiliar terms and concepts. To achieve a common understanding, these terms and concepts are defined in Appendix A: Glossary of Terms and Acronyms. These items are highlighted upon first use in the text for easy reference to the Glossary.

Thus, an underlined item in the text is defined in the Glossary, for example, Migration Plan.

The purpose of the Judicial Information System (JIS) Migration Plan is to provide a guide for transforming the JIS Application Portfolio to a set of Web Applications using a new architecture. The scope of migration includes the statewide JIS database and seven JIS Court Enterprise Applications, including JIS, SCOMIS, JRS, ACORDS, JABS, JTS, and CAPS.¹

Redeveloping legacy applications is a very large undertaking involving 241 court business processes and 338 application process modules, most of which are mission critical. The Migration Plan identifies twenty-eight (28) projects that will incrementally transform the older legacy applications in the JIS Application Portfolio (JIS, JRS, and SCOMIS) to the Web and assure the integration and reuse of the newer Web-based applications (ACORDS, CAPS, JABS, and JTS) where possible. (See Section IX, Migration Project Recommendations.)

The move to the Web is the JIS Committee's (JISC) strategic solution to two serious problems:

1. Legacy applications inadequately support future statewide information sharing plans.
2. Legacy applications are complex, difficult to use, inflexible, and do not adequately support changing business needs such as electronic filing and data exchange.

Successful migration to the Web hinges on the verity of the following policy level propositions:

1. The JISC goal is an integrated statewide application with limited court level features.
2. The JISC and users are committed to migration; moving to the Web is desirable.
3. The JISC goal is achievable with limited resources.
4. Incremental migration development will occur over a six-year period.
5. Legacy system changes are restricted to only emergency/mandatory items.
6. Costs are acceptable to the Legislature.
7. The high risks of this endeavor are acceptable to the courts and Legislature.

The total cost of migration is $38 million over three biennium budget cycles:

1. 2001-2003: $8 million
2. 2003-2005: $15 million
3. 2005-2007: $15 million

To manage this transition, the Migration Plan describes a process that:

1. Assures an orderly transition to the Web for both the JIS and court operations;
2. Optimizes the long-term benefits of Enterprise Application Architecture;
3. De-emphasizes the costly tradition of court level application architecture; and,
4. Mitigates the impact on courts working with both the legacy and Web systems.

The court community and the Judicial Information System Committee (JISC) are calling for the transformation of the Judicial Information System's (JIS) Application Portfolio to the Web with graphical user interfaces (GUI). This is a dramatic technological shift. The demand for this transformation is generated by deficiencies in the way JIS mainframe applications function and in limitations to the depth and ability (robustness) of JIS legacy applications to meet new business requirements.

The JIS Migration Plan deals with evolving JIS software, closing the technology gap, and moving the JIS to the Web. Specifically, the Migration Plan deals with the following problems:

1. How to move the aging, very large, and complex legacy JIS, the Judicial Receipting System (JRS), and the Superior Court Management Information System (SCOMIS) applications from a text-based platform to the Web.
2. How to coordinate all JIS Web-based initiatives, including the refactoring² (design adjustments) needs for the recently developed Web-based ACORDS, JABS, JTS, and CAPS applications.
3. How to achieve the goal for an enterprise-wide migration to the Web effectively and successfully within a reasonable timeframe of three-six years.

The Judicial Information System (JIS) portfolio is comprised of seven court applications that are, to a significant degree, islands of automation. Efforts to bind them together have been made on an on-demand basis to meet specific business needs like accounting, criminal history, and domestic violence. These application integration efforts have sometimes resulted in bridges that link the applications, but also add complexity to impacted business processes at both the application and court operation levels. To date, efforts to integrate the legacy and Web-based applications have been minimal.

The current JIS Application Portfolio is partially integrated, but significant levels of functionality remain redundant and isolated from the rest of the court enterprise as shown in Figure 1.

As complexity is added to the JIS Application Portfolio, the three older application designs become more brittle, more subject to breakage (bugs), more resistant to change, and more expensive to maintain, generating decidedly negative consequences. A decidedly negative consequence is that these factors are driving courts away from using JIS legacy applications. Continuing to modify the JIS legacy Application Portfolio in the fashion of the last decade is now too expensive and time consuming to effectively meet both the changing business needs of clients and the strategic goal of an Enterprise Application Architecture. The applications in this status include those in the legacy Application Portfolio.

Also in the JIS Application Portfolio are four new Web-based applications. As initial Web-efforts, these early JIS Web Applications embody issues that must be addressed as a part of the overall Migration Plan. For example, non-compliance with one or more OAC Application Architectural Standards due to technology issues remains a problem for each of these Web Applications. When solutions are found, they must be refactored into the design of these new applications. And, until solutions are available, migration of legacy applications must deal with the same problems.

Applications in the JIS, their status and future, are reviewed and summarized below:

1. JIS

The JIS includes DISCIS, JASS, DV, and Person application modules used by the limited jurisdiction, juvenile, and superior courts. The JIS application is now 11 years old and in that time has undergone major modifications to meet strategic goals and changing business needs. The cost and time to continually modify the JIS is increasing because its architecture has crossed the point of diminishing returns in its complexity and cannot successfully respond to the new JISC strategic direction and to rapidly changing business needs. The future of this application is in migration to the Web.

2. SCOMIS

The Superior Court Management Information System (SCOMIS) is 26 years old. SCOMIS application functionality remains largely unchanged and lags behind changing business needs as demonstrated by a large number of change requests. SCOMIS was the only application used by the superior courts until the JIS Person, Accounting and Domestic Violence modules were modified for superior court use during 1993-1997. Because the SCOMIS application architecture is isolated from companion accounting, case filing, and order modules in the JIS application, Bridge Application modules are necessary to interface with the JIS application, but these bridges are less than user-friendly. Today, then, in order to perform daily mission critical operations, both the SCOMIS, JIS, and JRS applications must be used by all superior courts. The future of this application is in migration to the Web.

3. JRS

The Judicial Receipting System (JRS) is a five-year old application with a Graphical User Interface (GUI) used by superior courts. Because the JRS application architecture is isolated from companion accounting modules in the JIS application, Bridge Application modules are necessary to interface with the JIS application, but these bridges are less than user-friendly. While the JRS application itself is flexible and efficiently supports receipting processes, the application's standalone architecture lacks network support that is critical for business operations with multiple receipting stations. The future of this application is in migration to the Web.

4. ACORDS

The Appellate Court System (ACORDS), a Web-based application, is for supreme and appellate court use, and is currently in pilot status. The future of this application is in its potential reuse in the migration of other legacy applications to the Web.

5. JABS

The Judicial Access Browser System (JABS) is a Web-based application for superior and limited jurisdiction court sharing of case and order history, and is currently in production status statewide. The future of this application is in the assessment of its potential for reuse and in its capability to effectively replace the legacy case history application modules.³

6. JTS

The Juvenile Tracking System (JTS) is a Web-based application, an off-the-shelf purchase, and is intended for use by juvenile courts (to replace JUVIS) and by Probation Departments in courts of limited jurisdiction. Replacing the earlier Juvenile and Corrections Integration (JCI) Project (also intended to replace JUVIS), the JTS product is being modified by the vendor to meet Washington requirements, and is currently in development status. The future of this application is in the assessment of the feasibility of supporting its non-compliance with the JIS application architectural JAVA standard.

7. CAPS

The Court Automated Proceeding System (CAPS) is a Web-based application for superior court use, to augment the other three legacy applications used by superior courts, and is currently in design status. The future of this application is in its completion and capability for integration with the Web applications that will replace the SCOMIS application for superior courts and the JIS application scheduling functions for limited jurisdiction courts.

The direction to move the JIS to the Web extends the JISC's prior commitment to case management systems via an integrated database and a common Enterprise Application Architecture. It focuses on more efficient court and criminal justice system operations with easier and modernized access to court information. The current strategy emphasizes data exchanges and improvements that will enable attorneys and the public to conduct electronic business with the courts over a secure Internet connection.

Data exchanges at local and state levels lower costs, enable courts to better integrate local criminal justice systems, eliminate duplicate data entry, and increase data accuracy, consistency, and timeliness.

Electronic filing provides significant increases in internal administrative efficiency for courts, enabling the same staff to process more cases. Electronic filing also improves customer service by speeding up both case transactions and access to case documents.

However, neither electronic filing nor efficient data exchange is possible unless the legacy JIS Application Portfolio is converted to a Web architecture. Cost-effective electronic filing requires a Web browser client for case management systems to facilitate electronic data transfer or original data entry by court users. Data exchanges using the Internet XML standard enable agencies to cost-effectively exchange data without having to re-engineer and tightly integrate many major computer systems. The JIS legacy applications do not provide a Web browser client and therefore cannot accommodate these initiatives.

The tactical plan for moving JIS applications to the Web includes:

1. Building New Web-based applications.

Use of a design approach (Object Oriented Development) that will produce more flexible systems and speed delivery of new systems over the long run. The ACORDS and CAPS applications follow this path.

2. Purchasing New Web-based applications. The JTS application follows this path.
3. Moving legacy JIS applications (JIS, JRS, & SCOMIS) to the Web.

The business processes supported by these applications will have to be sequentially redeveloped over a period of years. To entirely replace these applications in the short-run is too expensive. The JABS application follows this path by migrating JIS case history functions to the Web.

Managing Transitions

The Migration Plan offers some fundamental choices for the modernization of the JIS during the next three-six years. Because the JIS is a large and complex Application Portfolio that supports mission critical court operations, expectations that it can be moved to a Web-enabled, graphical user interface (GUI) environment easily and in a short period of time are unrealistic.

The intent of migration planning is to manage change and manage software evolution by defining a process that:

1. Assures an orderly transition to the Web for both the JIS and court operations;
2. Optimizes the long-term benefits of Enterprise Application Architecture; and,
3. De-emphasizes the cost-prohibitive tradition of court level application architecture.

The goal of migration planning, therefore, is to establish a philosophy for approaching and achieving this transition. This philosophy includes a set of migration principles and reasonable expectations that can be used to guide decision making about migration projects during a transition period of some duration.

Dwight D. Eisenhower once said: "Planning is essential. The plan is inconsequential." Likewise, migration planning is a dynamic process for achieving the intended result–moving the JIS to the Web. As migration projects are pursued over time, business, strategic, and technological environment changes may necessitate planning adjustments and shifts, but migration planning itself will need to be managed to continue and succeed.

Migration planning identifies a set of projects that will incrementally transform the legacy applications in the JIS portfolio to the Web. Migration project deliverables can include:

• A conversion of legacy requirements as imbedded in legacy applications;

• A re-write of legacy requirements as needed by changed/new business needs;
• Support of new requirements, including existing legacy application change requests, as defined by the users and when accepted by project stakeholders as being cost-beneficial;
• Correction of existing user-level problems in legacy.

Coordination of migration projects at several levels will be essential to establishing a common application infrastructure as shown in Figure 2.

The scope of the JIS Migration Plan includes the JIS database and all Court Enterprise Applications.

Definitions:

A Court Enterprise Application is one that supports mission critical business needs and is intended for statewide use by court staff in multiple court levels, or when applicable, in a single court level.

Excluded from the scope of the plan is the JIS-Link, a derivative application that allows non-court organizations and individuals to view court information via a modem with dial-up access.⁵

Future migration projects will continue using the JIS statewide database as the target data repository. The current JIS table structure and data model, however, may require modifications that provide better support to the technical demands of the Web Applications. This could result in a migration of the legacy data tables to a different data model that is designed to serve the Object Oriented Web Applications more than the procedural legacy applications. Or, it could result in the addition of new parallel table structures and bridge processes to populate both so the legacy applications can temporarily continue to access the legacy tables and perform business processes that have not been migrated to the Web. Either way, the data model will need to evolve to fit the new Enterprise Application Architecture.

The seven JIS enterprise applications⁶ listed in the chart below are targeted for migration planning and include both legacy and Web applications. The three legacy applications are redevelopment projects and occupy most of the migration planning landscape. The four Web-based applications have smaller migration planning scopes, focused on design modifications.

Together, these seven enterprise applications represent 338 implementations of court business processes that are essential to court operations in the state of Washington. The number of processes in each application is summarized below.

The major work to migrate the legacy applications to the Web entails the potential redevelopment of 193-court business processes. Other migration work includes the assessment of the 145 processes in the Web Applications to determine their potential for reuse.

Three types of assumptions underlie migration planning: policy, business, and technical.

The assumptions listed below represent requirements for a stable and predictable migration development environment. These assumptions will be true to some extent in each migration project. The degree to which any assumption is untrue will be reflected as a migration risk factor that can affect the cost and duration of any impacted migration project (see Section VIII, Migration Risk Management). Each project team will also need to analyze its own project's scope for the existence and impact of other underlying assumptions unique to that project.

1. Budget and staff resources are limited
2. Six-year budget: $8 million in 2001-2003; $15 million each in 2003-2005 and 2005-2007
3. Integrated statewide system is a JISC goal
4. Single court-level applications are unacceptable for the enterprise, with few exceptions
5. Costs are acceptable to the Legislature
6. Risks are acceptable to the courts and Legislature
7. Legacy system changes are restricted
8. Moving to the Web is desirable

1. Legacy system components will be operational for up to six more years
2. Cost-beneficial bridges between legacy and Web applications are necessary
3. Operational impacts exist
4. Legacy data will be preserved
5. Court community is committed to participating in the migration process

1. Three-tier architectural standard is operational
2. Uniform application architecture will be achieved to maximize reuse
3. Current three-second application response time standard can be extended to the Web
4. Sufficient network bandwidth will exist to assure performance
5. Continued legacy application maintenance is restricted to mandatory items
6. Current JIS database model is adequate for Web applications
7. OAC application architectural standards are institutionalized⁷ at the OAC
8. OAC capability maturity level is ready to support the migration process
9. An Enterprise System Architect and a librarian are available resources
10. A court enterprise application architecture model exists as a starting point
11. Scope of migration project tasks are well defined

The degree to which each migration project can rely on its project assumptions and can manage its migration risk factors will influence project success. Managing project risks involves identifying risk factors, their impacts, and possible mitigation strategies so that each risk factor is acknowledged and planned for in terms of contingency cost, time, and oversight control.

At the present time, all migration projects share several risk factors and will continue to share them until they are mitigated by the implementation of long-term solutions. Each risk factor is assigned a risk level that is based on an analysis of the following criteria:

• Probability of the risk occurring
• Impact on citizens, court operations, OAC budget
• Impact of not dealing with the risk
• Development effort, staff capability, and use of proven vs. bleeding-edge technology

Migration project risks are summarized below with their probability and impact ratings and are ranked in order of their overall risk level (high, medium, or low).

Besides these, each migration project will have additional risk factors that are unique to it. At the policy level, all risk factors that are identified for a migration project must be acceptable to sponsors, stakeholders, and users alike in terms of the probability of occurrence and impact, and must be manageable, and incorporated in the project plan with mitigation alternatives and contingency costs.

Transforming the JIS Application Portfolio to the Web needs to be approached within the context of Strategic Goals, Development Objectives, Legacy Applications, Resource Allocation, and individual Migration Projects. Each of these items is discussed below.

All strategic goals address court business from the enterprise level and these must be a priority for each migration project, including:

1. Cross-Jurisdictional Scope
2. Modernization of Functionality and User Interface
3. Data Exchange
4. Electronic Filing
5. Business Process Integration
6. Preservation of Business Process & Operational Integrity
7. Extend Legacy Functionality
8. Redesign for Business Changes and Problem Correction
9. Modify Web Applications to Achieve Reuse

1. Incremental development.

Scheduled releases will add Web application functionality over time.

2. Optimize an enterprise level application migration.

Emphasis will be on business processes common to multiple court levels with the aim of eliminating redundant applications to realize a 30 percent saving over current maintenance costs.

3. Legacy and Web-based application integration.

Each migration project must acknowledge and address the potential need for a legacy application interface. Any migration project that does not deal with the following question will fail. How can clients rely on the functionality of both legacy and Web functionality without critically disrupting business operations? Real user interface options must be explored in terms of the business impact and cost.

4. Minimize project risk.

Managing risk and limiting project size will optimize success potential.

Legacy application modules are valid resources for mining the functional design of business processes, and for migrating them to new Web Applications. The purpose of mining is to reuse valuable functional designs at the enterprise level for large-scale systems. Reuse simplifies requirements gathering and can minimize design modifications.

Each migration project will need to assess the quality of the legacy application modules for the business processes within its scope. By using the following types of assessments, each migration project can determine the extent to which it will mine legacy application designs and plan for design modification tasks.

• Enterprise Quality - the application's level of cross-court versus redundant support of business processes common to different court levels.
• Functional Quality - the application's level of completeness for supported processes.
• Technical Quality - the level of unresolved flaws in the application for supported processes.
• Complexity - the application's ease and cost of maintenance and testing.

The flip side of the incremental development of Web Applications is the incremental dismantling of the JIS legacy applications. And, until dismantling occurs, maintenance must continue.

Managing the JIS Application Portfolio in the migration environment is about managing the coexistence of legacy and Web-based applications. Legacy applications or parts of them will need maintenance for at least six years before their functionality can be fully replaced by Web-based applications. Therefore, it will be necessary for the new Web-based applications to coexist with the legacy applications as migration proceeds at a steady pace.

To what degree, then, shall legacy applications be enhanced and maintained while the enterprise undertakes strategic migration projects? If the strategic goal is to optimize migration to Web-based applications, then committing resources to legacy application maintenance must be limited to a level that maintains critical operations and restricts legacy application modifications by following the criteria, below.

1. Complete data repair requests;
2. Complete emergency program fixes;
3. Complete only the most essential legacy codes table changes as approved by the JIS Advisory Committee;
4. Complete maintenance required by non-discretionary application support software upgrades;
5. Complete small mandatory legislative, court rule, or data dissemination policy changes for legacy business processes not involved in a migration project that is currently underway;
6. Redirect all non-mandatory business process change requests and legacy application problem reports to the appropriate migration project, not to legacy maintenance projects and tasks;
7. Direct all development of new business processes and all mandatory medium-to-large legislative changes to the appropriate migration project.

Implementing these restrictions would mean that the lists of 1200 change requests and non-emergency problem reports for JIS legacy applications would be addressed only in the context of migration or other strategic projects. These problems and changes would not be addressed by modifying the legacy applications. Implementing these restrictive maintenance scenarios would also require more explicit guidelines for decision making on maintenance requests.

Twenty-eight migration projects are identified in the Migration Project Portfolio. Most are enterprise level projects for statewide use by multiple court levels; some apply to a single court level. The JIS Committee's strategy demands a shift away from developing court level-based applications. Therefore, migration planning excludes the redevelopment of single, monolithic court-level applications for all functionality that is common to more than one court level.

Projects are listed in their proposed sequential order which is based on a combination of factors, including current JISC priorities, court operational needs, development opportunities, the OAC staff experience and Capability Maturity level, budget and resources, and political decisions. Actual development sequence can be relative depending on changing priorities, resources, and the number of projects being developed simultaneously.

Footnotes

² Refactoring is changing one solution to another solution with an improved structure that provides increased benefits.

³ For example, the JIS Individual Case History (ICH), Individual Order History (IOH), Case Order History (COH), and Domestic Violence Inquiry (DVI) screens.

⁴ Use the contact information to get a copy of a complete copy of the JIS Strategic Plan.

⁵ For the immediate future JIS-Link on the web would involve only a change in connectivity and the application would include exactly the same character based screens that are now available. When JIS applications move to web browsers and GUI interfaces, JIS-Link will change too.

⁶ For a more general description of the legacy JIS applications, see JIS Applications.

⁷ See the OAC APPLICATION ARCHITECTURAL STANDARDS (Please contact the OAC for a copy.)

⁸ The results of the JTS assessment will validate the need for and sequence of migration projects 26-28.

⁹ Actual project sequence will be determined by the JTS assessment in migration project #2.

A PDF version of the JIS Migration Plan is available for printing.