Exhibit A - Data and Infrastructure

Data and Infrastructure

Interfaces and Data Exchange

Interfaces and Data Exchange includes the activities associated with design and development of constructs to transfer data real time, on demand, and daily bi-directional data from the County’s current internal and external systems to the proposed solution. The County is seeking a vendor with a mature API-based integration framework thereby limiting the number of custom and one-off integrations that will need to be developed.

There will exceptions for certain purpose-built, “bolt-on” applications that have been implemented to enhance or extend the CCMS or JMS solutions (i.e., Picture Link, which stores mugshots for the JMS or Keefe for inmate accounting and commissary). Vendors that have defined interfaces with these applications will be expected to define the nature of and reusability of the interfaces. For all other integrations, the County is contracting a specialist system integrator to support the design and development of the enterprise Data Integration Hub (DIH) that the proposed JMS/CCMS will be required to integrate with.

Phase 1: Implementation and Configuration of the DIH tool.

As part of this phase, the DIH vendor will migrate and manage legacy data exchanges, as well as building the structure and business rules to house data from the legacy JMS and CCMS modules

Phase 2: Support JMS integration messages

The JMS vendor will develop the necessary messages and APIs to the various companion applications (such as Keefe), and will develop the messages to the DIH that will be supported between the DIH and the legacy JMS in order to replace and retire those messages. The current JMS data to be pushed to the DIH will, at a minimum, include:

• Bookings and Releases

• Custody Status

• Housing Location

• Current Location

• Sentencing/Release Date

The vendor will expose these data elements to the DIH in a standard (preferably NIEM) format for consumption by subscribing systems.

The JMS will also receive data from legacy IJIS applications, directly or through the DIH. These will include, at a minimum:

• Warrant data

• Bond information

• Adjudication and sentencing information

• Court Settings

• Prosecutor charging decisions

Phase 3: Support CCMS Integration Messages

The CCMS vendor will develop the necessary messages and APIs to the DIH that will be supported between the DIH and the legacy CMS in order to replace and retire those messages

The CCMS will also receive data from the new JMS and legacy IJIS applications, directly or through the DIH. These will include, at a minimum:

• Court Filings

• Custody Status

Phase 4: Support Additional JMS Integration Messages

As part of the second implementation phase of the JMS, additional integration messages may be identified and developed. An example would be Arrest records from Law Enforcement Agencies to support pre-booking activities.

Refer to Exhibit B: JMS Technical Requirements and Interfaces for an outline of identified County interfaces.

Reference Table 9 on the Reference Information Page is meant to provide additional detail with anticipated data exchange complexity and transaction volumes.

The following table identifies the general roles and responsibilities with respect to configuration, and testing of Interfaces and Data Exchange, where RACI (Responsible Accountable Consulted Informed) designation(s) are assigned to indicate the roles and responsibilities of each organization in performing and/or completing the activity or task:

Interfaces and Data Exchange Roles and Responsibilities

Interfaces and Data Exchange Roles and Responsibilities

Successful Responder

County Output/Outcome

• Create interface and data exchange specifications from the new system to County target systems and/or DIH for the interfaces and data exchanges listed in Exhibit B - JMS Technical Requirements.

R, A R, C Interface & Data Exchange specification document

2. Approve interface and data exchange design specifications.

I R, A Documented approval

3. Develop target interfaces and data exchanges according to approved specifications (API specification)

R, A - Interface & Data Exchange specification document

Interfaces and Data Exchange Roles and Responsibilities

Successful Responder

County Output/Outcome

4. Produce all necessary “transaction monitoring” capabilities to support the interfaces effort as detailed in the Interface & Data Exchange specification.

R, A R, C Documented successful test results

5. Execute all tasks including the setup of the interfaces to County and external systems in compliance with the Interface & Data Exchange specification documents in an iterative process

R, A - Documented successful test results

6. Execute the transformations and rules that were used to map the legacy and target environments to include data clean-up tasks in an iterative process

R, A - Documented successful test results

7. Create and develop interface and data exchange test plan

R, A - Interface & Data Exchange test plan

8. Review and approve interface and data exchange test plan

I R, A Documented feedback and approval

9. Create and develop implementation test plan R, A - Interface & Data Exchange test plan

10. Review and approve implementation test plan I R, A Documented feedback and approval

11. Build, test, and validate environments R, A - Documented successful test results

12. Build, test, and validate “sand box” environments

R, A - Documented successful test results

13. Test the interfaces, according to the interface and data exchange test plan, to ensure they comply with the interface and data exchange design specifications and data mapping after each iteration

R, A - Documented successful test results

Interfaces and Data Exchange Roles and Responsibilities

Successful Responder

County Output/Outcome

14. Test all previously completed system interfaces in accordance with the Interface and Data Exchange test plan after each iteration.

Interfaces will comply with business and system technical requirements identified.

R, A - Documented successful test results

15. Present reports and results, including capacity and load, after each iteration

R, A I Documentation as described

16. Review and approve reports and test results I R, A Testing results report

17. Ensure and verify that the exchanged data is accurate and complete.

R, A - Testing results report

18. Update and implement required data sharing agreements and MOUs with external agencies as per approved interface and data exchange design specifications.

I R, A Interface & Data Exchange specification document

Infrastructure and Environment

Infrastructure and Environment consists of technical hardware and software environment configurations and specifications (virtual or physical) necessary to operate the JMS solution. The following table identifies the general roles and responsibilities with respect to Infrastructure and Environment, where RACI (Responsible Accountable Consulted Informed) designation(s) are assigned to indicate the roles and responsibilities of each organization in performing and/or completing the activity or task:

Infrastructure and Environment Roles and Responsibilities

Contractor County Output/Outcome

1. Define software requirements for the JMS Infrastructure and Environment

R, A - Detailed infrastructure, environment, build and deployment plans and procedures

Infrastructure and Environment Roles and Responsibilities

Contractor County Output/Outcome

2. Create, develop, and define the strategy for stand-up of the Infrastructure and Environment

R, A - Detailed infrastructure, environment, build and deployment plans and procedures

3. Create, develop, and define the quality control procedures for the build of the JMS infrastructure and environment

R, A R, C Detailed infrastructure, environment, build and deployment plans and procedures

4. Create, develop, and define the security measures for the build and deployment of the JMS infrastructure and environment as required by the County

R, A R, C Detailed infrastructure, environment, build and deployment plans and procedures

5. Create, develop, and define the testing plans and procedures for the build and deployment stages of the JMS infrastructure and environment

R, A C Infrastructure, environment, build and deployment test and validation plan

6. Create and develop the documentation as required for the build of the JMS infrastructure and environment

R, A C Detailed infrastructure, environment, build and deployment plans and procedures

7. Report on the status of the infrastructure and environment build and deployment as required

R, A I Documented status report

8. Work collaboratively in the creation and configuration of all infrastructure and environments

R, A R, C Workshop attendance and minutes

9. Review and approve all plans and procedures

- R, A Documented feedback and approval

10. Deploy the production infrastructure and environment

R, A C Documented successful test results

11. Conduct quality assurance, security, functional, and technical testing, and correct all unsatisfactory test results

R, A R, C Documented successful test results

12. Build, test, and validate infrastructure environments

R, A C Documented successful test results

Infrastructure and Environment Roles and Responsibilities

Contractor County Output/Outcome

13. Build, test, and validate “sand box” infrastructure environments

R, A C Documented successful test results

14. Review and approve test results R, C R, A Documented feedback and approval

15. Set disaster recovery expectations I R, A Documented recovery recommendations

16. Create, develop, and provide disaster recovery plan

R, A C Disaster recovery plan

17. Approve disaster recovery plan I R, A Document approval

18. Set business continuity expectations I R, A Documented business continuity expectations

19. Create, develop, and provide business continuity plan

R, A C Business continuity plan

20. Approve business continuity plan I R, A Document approval

21. Provide audit access and participate in scheduled or unscheduled audits

R, A - Monitoring and incident management plan and procedures

22. Provide automated monitoring and incident notification functionality

R, A - Monitoring and incident management plan and procedures

23. Provide automated monitoring and incident notification services

R, A - Monitoring and incident management plan and procedures

24. Monitor and validate DOJ, CJIS, NIST, CLETS, security, etc. compliance

I R, A Monitoring and incident management plan and procedures

Integration and User Acceptance Testing

Integration and User Acceptance Testing includes the activities associated with a seamless implementation. The following table identifies the general roles and responsibilities with respect to Integration and User Acceptance Testing, where RACI (Responsible Accountable Consulted Informed) designation(s) are assigned to indicate the roles and responsibilities of each organization in performing and/or completing the activity or task:

Integration and User Acceptance Testing Roles and Responsibilities

Contractor County Output/Outcome

1. Create, develop, document, and maintain integration and testing plan that meets requirements and adheres to defined policies.

R, A C System Integration and User

Acceptance test plan

2. Provide proposed integration and testing plan R, A - System Integration and User

Acceptance test plan

3. Review and approve integration and testing plan I R, A Documented approval

4. Create and develop interface test plan for pre-production SIT / UAT

R, A C System Integration and User

Acceptance test plan

5. Review and approve interface test plan I R, A Documented approval

6. Recommend integration and testing requirements R, A I System Integration and User

Acceptance test plan

7. Build, test, and validate environments R, A - Documented successful test results

8. Build, test, and validate “sand box” environments R, A - Documented successful test results

9. Approve integration and testing requirements I R, A Documented approval

10. Manage integration test environment (SIT) R, A Status reports

Integration and User Acceptance Testing Roles and Responsibilities

Contractor County Output/Outcome

11. Manage issue tracking software solution for tracking defects, progress, and proposed resolutions

R, A I Risk/Issue Log

12. Maintain software release matrices across development, quality assurance, and production environments and networks

R, A I Status reports

13. Conduct integration and security testing for all systems (such as data, equipment, and networks), based on requirements defined in the plan and MN DOC / MNIT policies and procedures

R, A R, C Documented successful test results

14. Evaluate all new and upgraded system components for compliance with Clayton County security rules, regulations, and procedures

R, A R, C Documentation

15. Assess and communicate the overall impact and potential risk to system components prior to implementing changes

R, A C System Integration and User

Acceptance test plan

16. Create and develop User Acceptance Testing ("UAT") requirements and scripts

C, I R, A System Integration and User

Acceptance test plan

17. Create and develop UAT plans and scripts per requirements

R, A - System Integration and User

Acceptance test plan

18. Review and approve UAT plans I R, A Documented feedback & approval

19. Conduct and document UAT results per requirements

I R, A Documented successful test results

20. Support UAT testing R, A - Status Reports, attendance, and minutes

21. Review and approve UAT results I R, A Documented feedback & approval

22. Execute interface test plan R, A I Documented test results

(verification of execution)

Integration and User Acceptance Testing Roles and Responsibilities

Contractor County Output/Outcome

23. Share all test results with successful Responder R, A R, C Status report

24. Identify, remediate, and resolve any problems with the successful Responder’s product, JMS configuration, data conversion, or with the integration or interfacing of their product with those of other third-party Contractors and County.

R, A C, I Successful test results

Data Conversion & Migration

The successful vendor for both the Jail Management System (JMS) and the Case Management System (CMS) modernization in Clayton County will have significant responsibilities related to data conversion and migration from the legacy CPU8 mainframe and other systems. Migration sources may be impacted by the Data Integration Hub (DIH).

A detailed data conversion plan will be required as part of the JMS/CMS implementation. The successful responder will need to convert all legacy records into the COTS solution. The County must be able to validate successful conversion/migration of their existing JMS/CMS data to the new COTS solution. The successful responder will work with the County to successfully convert the active and historical data defined as in scope.

The responder will be expected to actively lead and participate in identification of source data, data mapping, data quality assessment and performance of multiple mock migrations. The responder will advise the County on quality issues that negatively impact the completeness of the conversion of date, providing reports of what records are not converting and why. The responder will provide guidance on data cleansing activities that the County would need to perform.

The DIH vendor will be charged with creating a repository of the legacy JMS/CMS data and in the course of ingesting and syncing that data with the legacy CPU8 mainframe, will be applying data governance and cleansing rules to that data. The DIH should be evaluated as part of the migration as a source for the legacy data for the JMS and CMS projects.

Data Conversion and Migration Responsibilities

The vendor selected for the system integration role is expected to manage and execute the process of converting existing data into the new COTS/DIH solutions and outline approach to data conversion.

Key responsibilities include:

1. Defining the Methodology and Tools: The vendor must define and support the migration of data, providing detail on the methodology and tools that will be leveraged for migration, along with the responsibilities of the County and the vendor.

2. Conversion Planning: The procurement documents require the submission of a Detailed Data Conversion Plan(s) and a Detailed Data Migration Plan(s) during the Configure/Build phase of the project (see Exhibit G - JMS Project Gates).

3. Data Cleansing: Prior to conversion, a Detailed Data Cleansing Plan(s) must be developed by the vendor, focusing on identifying data sources required for migration and thoroughly understanding the data to be cleaned.

4. Execution of Conversion and Migration: The vendor is responsible for conducting the Data Conversion(s) and Migration(s) to the County's specifications.

5. Quality Assurance and Validation: The County expects the vendor to provide documentation identifying records that could not be converted, including appropriate reasons for the failure, to allow the County to rectify data issues and perform additional conversion. The successful conversion/migration must be validated by the County.

The Role of the Data Integration Hub (DIH) in Migration

In the Clayton County program, the Data Integration Hub (DIH) will run in parallel with the JMS and CMS implementations and plays a central role in managing data as it is shared among justice partners, and also to create a repository of justice data (including but not limited to booking and release, court filings judgements and sentences). That repository will be evaluated as a potential source.

The strategic intent related to data migration and the DIH includes:

• Data Preparation: Conduct a Data Quality Assessment and Data Prep for populating the repository and Future Migration, which feeds into the requirements gathering for the DIH initiative.

• Replicated and Synced Data from the Legacy Systems: Starting with CPU8, the DIH will be a direct reflection of the active and historical records for the Jail and the Courts, with ongoing integration messages keeping that data in sync. Additional data sources may be identified and their data migrated into the repository.

• DIH as a Potential Source for Migration: The DIH initiative includes a Data Foundation component that aims to begin addressing data quality, cleanliness, and completeness. This foundational work can contribute to and shorten data migration efforts for CMS and JMS implementation, potentially being the source for migration.

• Data Exchange Capabilities: The goal of modernizing data sharing is to overcome limitations of the legacy system, where integrations were often manual or "one-off point to point". The JMS and CMS solutions must integrate with the DIH for seamless data flow, including custody status, housing location, and current location, in near real-time.

Therefore, while the vendors for the JMS and CMS are ultimately accountable for migrating the necessary historical and transactional data into the new solution, the DIH is intended to manage data governance, cleanse source data (from CPU8), and act as the centralized platform for sharing that data, which assists in the migration process for the system integrators.

Go-Live Criteria for Data Readiness

Final acceptance of the CMS and JMS solutions and readiness for "Go-Live" is contingent on meeting specific data requirements.

A critical criterion is Data Readiness, which mandates that data migrated from source systems (like CPU8) to the new vendor solution must have completed Quality Assurance (QA) and satisfy four essential requirements regarding data severity issues:

No Severity 1 issues (showstopper/major system errors).

No Severity 2 issues (significant loss of feature functionality).

All Severity 3 issues must have identified workarounds agreed upon with the County and communicated to users.

All Severity 4 issues must be identified, agreed, and documented