DOC

1,427 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,427
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
28
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

DOC

  1. 1. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE 6.6 Implementation • Subsection 6.6: Implementation This subsection must include a narrative describing the QBP’s approach to implementation, interface management, and data conversion; and sample Implementation, Interface Management and Data Conversion Plans used by the QBP on another project or projects as described in Section VI.D.9 – Implementation VI.D.9.Implementation Req. Requirement Response / Reference Num. M-56 The Contractor shall describe the implementation approach and Section 4.2.D, methodology used for the SOMS Project. Section 6.1, The Bidder must submit a narrative describing the Vol 1 – Appendices implementation approach and methodology with their Appendix A, proposal response as identified in Section VIII – Proposal and Bid Format. Section 6.8 Bidder Response Detail: Team EDS’ approach to implementing the Strategic Offender Management System (SOMS) is framed by our strategy to roll out functionality incrementally and by our overall Project Management Version 2 (PM 2®), EDS’ Project Management methodology. Section 4.2.D, Phasing, describes our incremental rollout of SOMS and explains the rationale for our phasing plan and its dependencies, constraints, and schedule. Meanwhile, Section 6.1, Project Management, and our draft Project Management Plan, Appendix A, describe our approach to managing SOMS as a project consisting of the following nine projects: • Project Management Office (PMO) – startup, operation, and closing of the PMO • Infrastructure delivery – assessment and deployment of the enterprise system architecture and related infrastructure needed for delivery of each project and its associated components, including hardware, software, and tools for the five system environments • Electronic Records Management System (ERMS) –conversion of existing paper documents contained in C-files, parole field files, and juvenile files into electronic images; procedures for “day forward” processing of paper documents • Phase I/Release 1A – configuration and implementation of the initial business functionality for adult institutions (Intake, Movements, and Scheduling functions) • Phase I/Release 1B – configuration and implementation of additional business functionality for adult institutions (functions include: Sentence Calculation; Classification; Programs; Gangs; Holds, Wants, Detains; and Discipline) • Phase I/Release 1C – configuration and implementation of remaining business functionality for adult institutions (functions include: Transportation, Property, Visits, Appeals and Grievances, and Administrative processes) EXHIBIT I-6 EDS SOMS STATEMENT OF WORK
  2. 2. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE • Phase II/Release 2 – configuration and implementation of adult parole and pre-parole processes • Phase III/Release 3 – configuration and implementation of business functionality for juvenile institutions and juvenile parole offices • Maintenance and Operations – establishment of production support for the SOMS project and transitioning of system operations to the State of California Department of Corrections and Rehabilitation (CDCR). Figure 6.6-1, Implementation Approach, illustrates our phasing strategy and presents our overall deployment schedule for the nine SOMS projects. For each project, Team EDS will submit to CDCR a detailed Implementation Plan that follows the overall implementation approach summarized in Figure 6.6-1. Year 1 Year 2 Year 3 Year 4 Year 5 PMO Startup Program Planning and Initiation Infrastructure Intake, Movements, 1A Scheduling Phase I: Adult Sentence Calculation, Classification, 1B Programs, Gangs, HWDs, Discipline Institutions Transportation, Property, Visits, Appeals, Administrative Functions 1C Phase II: Adult Parole Pre-Parole and Parole Operations 2 Phase III: Juvenile Juvenile Institutions and Parole 3 Operations Adult Institutions Electronic Records Juvenile Management System Institutions (ERMS) Parole Production Support Maintenance & Operations Transition & Warranty Acceptance Figure 6.6-1, Implementation Approach Our approach to implementing the SOMS projects is founded on our tracks-based approach to aligning work activities and organizing the Delivery team. For our tracks-based approach, we assign a dedicated team to each of the distinct activities required to implement SOMS; for example, one track lead oversees the team responsible for software configuration, a second lead oversees the team focused on data conversion, a third is assigned to interfaces, and so forth. Using our tracks-based approach, implementation is a separate track that is managed by an experienced Implementation team, which focuses solely on implementation EXHIBIT I-7 EDS SOMS STATEMENT OF WORK
  3. 3. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE planning and system rollout. The tracks-based organizational structure affords integration with activities that are interdependent with implementation, such as infrastructure readiness, software configuration, interface development, and data conversion. Through this approach, the implementation manager directs implementation activities, drawing resources from track leads as needed. Figure 6.6-2, Activities to Support Implementation Management, identifies the framework and activities involved in implementing the SOMS project and illustrates how various tracks support the overall implementation of each project. Figure 6.6-2, Activities to Support Implementation Management, shows that our implementation of each SOMS release involves specific tasks in three general categories of activities: cutover planning, pilot testing, and rollout activities. In carrying out implementation activities, track leads and the Project Management Office provide expertise and support in the areas of change management, communication, training, documentation, operational support, testing, data conversion, and configuration management. Throughout the implementation cycle, the Implementation Plan specifies tasks and responsibilities to monitor and evaluate progress, confirm quality and manage the rollout of each SOMS release. A final implementation activity supported by the Project Management Office is to conduct a post-implementation review to make sure the release met the goals specified in the Implementation Plan, and to provide input into subsequent projects/phases. Determine Cutover Approach Determine Pilots Develop Implementation Strategy Change Data Configuration Communication Training Documentation Support Testing Management Conversion Management Conduct Conduct Conduct Needs Develop Conduct Support Develop Develop Conduct CM Readiness Com m unications Analysis Strategy & Plan Assessment Strategy & Plan Strategy & Plan Assessment Assessment Assessment Develop Develop Develop Develop Develop Develop Develop Decommission Strategy & Plan Strategy & Plan Strategy & Plan Strategy & Plan Prepare Strategy & Plan Tem plates & Strategy Test Plans Standards Deliver Change Develop Develop Develop Develop Service Coordinate Conduct Data Build Managem ent Comm unication Training Business/Tactical Level Agreement Test Data Analysis Design Environm ents Workshops Material Material Docum entation Review Conduct Train- Develop & Test Develop Online Select Help Desk Support Business the-Trainer Conduct Testing Data Conversion Help Software Environm ents Process Workshop Program s Align Business Maintain Establish Help Manage Develop CM Deliver Training Support UAT Processes Docum entation Desk Conversions Docum entation Validate Align Evaluate Manage Ongoing Rollout Software in Organization Training Support Production Production Monitor and Evaluate Progress Ensure Quality Manage Cutover Figure 6.6-2, Activities to Support Implementation Management Determine Cutover Approach The first set of activities in our implementation approach involves planning the cutover of each SOMS release. Team EDS will plan the rollout of each SOMS release by first conducting EDS SOMS STATEMENT OF WORK EXHIBIT I-8
  4. 4. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE a readiness assessment. As part of the readiness assessment, our team will examine infrastructure readiness and overall organizational and business process readiness. Thus, outputs from Business Process Management activities provide essential input into the readiness assessment. Outputs from the readiness assessment serve as input into the infrastructure delivery project and the On-Site Implementation Support Plan and shape the Change Management, Risk Management, and Training Plans. In conducting the readiness assessment for the Electronic Records Management System (ERMS), for example, our team evaluates network bandwidth, confirm availability of equipment at the institutions, validate business process changes involved in rolling out software release, and assess staff preparedness for the cutover. The Project Management team use outputs from the readiness assessment to integrate activities across projects and across track domains, including business process and change management, training, data conversion, testing, and software configuration. In accordance with the requirements of the Request for Proposals (RFP), we submit a Pre-Implementation Readiness Assessment document before CDCR’s user acceptance testing (UAT). In planning system cutover, a primary area addresses the challenges of coordinating data conversion with cutting over to the new system. Depending on details we learn in the Business Process Management activities, one alternative could be that we disengage legacy systems at the time we begin data conversion, and we cut over to the new system after data conversion is completed. Factors that weigh into coordinating data conversion with the cutover include the duration for data conversion, the impact of “freezing” the legacy system during the data conversion process, and the degree of on-site involvement for data conversion and cutover activities. If the duration of data conversion and the corresponding legacy system “freeze” is projected to negatively affect prison or parole operations, our team may mitigate the issue by engaging a two-step data conversion process, whereby users continue to use the legacy system while historical data is migrated. Then, just before cutover, we would make a second pass through data conversion to migrate recently entered data, disabling the legacy system only during the relatively brief second pass. Determine Pilot Testing Approach Team EDS will work with CDCR’s Project team to identify the locations in which we will conduct short-term pilot tests of the software release. During each pilot test, Team EDS works closely with institutional liaisons to test the release in parallel with legacy systems. Pilot tests will last no more than one week; depending on results of the pilot test, the team may determine that a second or third iteration of pilot testing is required. At the close of pilot testing, pilot test data will be discarded and the team will commence a limited scale rollout of the release, at which time, three institutions cut over to the new software. Implementing the release on a limited scale enables Team EDS to focus implementation resources at the three institutions, not only to be able to resolve implementation issues promptly, but also to prepare the Implementation team for full-scale rollout at all CDCR institutions. Our Implementation Plan determines the precise duration and location of limited scale rollout; based on our experience with previous implementations in other states, we anticipate the three-institution-implementation period to require between two weeks and four weeks. EXHIBIT I-9 EDS SOMS STATEMENT OF WORK
  5. 5. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE Develop Implementation Strategy Team EDS’ implementation manager will work with the CDCR Project team to develop a comprehensive, detailed Implementation Plan using our proven PM2® methodology. Our Implementation Plan draws on extensive experience of implementing our commercial off- the-shelf (COTS) solution in other state departments of correction, with detailed tasks based on CDCR pilot testing and associated lessons learned. As we have stated, Team EDS follows a two-step implementation approach whereby we deploy each release at three institutions in what our plan refers to as “limited-scale production rollout.” After full acceptance of the limited-scale rollout at the three institutions, our team will proceed to roll out the release at all sites. Our Implementation Plan describes how we engage CDCR staff for both limited scale and statewide rollouts; for example, at adult and juvenile institutions, a member of Team EDS will be on site at each location, working side by side with CDCR institutional liaisons and users. Depending on outputs from the “determine cutover approach,” the Implementation Plan will involve a concurrent, statewide rollout or, if conditions warrant, a rapid “rolling wave” of institutional deployments. For example, if we determine that multiple EDS team members are needed on site to cut over individual institutions to the release, we would propose a rolling wave implementation approach whereby we implement the release at a subset of sites concurrently, to achieve statewide deployment over the course of several weeks. Monitor and Evaluate Progress Team EDS formally monitors and evaluates progress with each incremental rollout of functionality. We determine the approach to monitor and evaluating the success of the implementation as the project unfolds. Through daily reports, we monitor implementation success at both the project and stakeholder level using strategies that we constantly update when the desired result is not being achieved. Our Project Management Plan specifies the format and frequency of progress reports according to the requirements of the SOMS contract. Manage Quality In the course of rolling out each release, the implementation manager and our quality manager jointly execute the Quality Management Plan, which we describe in Section 6.8, Quality Management. Employing our Global Applications Delivery Quality Management System (GAD-QMS), the quality manager defines specific qualitative measures in the Implementation Planning phase and will carry out activities to expose and document shortcomings early and throughout the implementation process. Our GAD-QMS methodology confirms systematic analysis and reporting of qualitative aspects to enable the Implementation team to take prompt corrective action. Manage Cutover Before cutover, we document and monitor detailed checklists of all business and technical readiness activities. EDS’ Implementation team will work with CDCR business experts and the Project team to take on this responsibility and drive activities through to completion before the cutover date. During cutover, Team EDS will direct the maximum number of resources available to implementation activities, including all training and business process management staff. The help desk serves as a central point of contact for on-site liaisons and EDS SOMS STATEMENT OF WORK EXHIBIT I-10
  6. 6. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE field staff to report issues during the implementation cycle. Using service desk software from Computer Associates, the help desk logs all reported issues, thereby enabling the implementation manager to direct issue resolution and to communicate progress and issues. Conduct Post-Implementation Review The purpose of the post-implementation review is to gather lessons learned for use with future releases. The goal is to obtain useful feedback about the effectiveness of the methods we use in each implementation area. Team EDS will gather, analyze, and document the data and provide CDCR with recommendations that can be incorporated into future implementations. The following is a list of sample implementation tasks that will be defined in the Implementation Plan and repeated for each SOMS release: • Create a Site Preparation Checklist • Install Required Hardware and Software • Implement all Security Changes • Provide Training to Site Staff • Convert Data • Conduct Implementation • Evaluate System Performance • Provide Application Support and a Help Desk. At the core of our implementation approach is the integration and use of our structured, proven project management policies. By using an integrated approach to project management, the Implementation team will have ready access to the same tools, methods, and procedures used by the Project Management Office for overall management of the project. This will hasten the identification, resolution, and mitigation of issues and risks, thus enabling the project’s overall success. EXHIBIT I-11 EDS SOMS STATEMENT OF WORK
  7. 7. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE VI.D.9.a. Implementation Plan Requirements Req. Requirement Response / Reference Num. M-57 The Contractor shall incorporate the implementation approach Vol 1 – Appendices into a comprehensive Implementation Plan. CDCR requires Appendix L, incremental deliveries of functionality to the production Section 4.2 environment. CDCR anticipates considerable collaboration with the Contractor in the plan’s construction, with particular attention to high complexity components of the existing Offender Management Systems as well as the proposed solution. The Implementation Plan shall: • Deliver solutions that include a significant portion of the technical infrastructure early in the schedule, without compromising the quality or inherent security of the solution. This should also validate the design and architecture. • Expose technically challenging areas of the project as soon as possible. New external interfaces, data conversion, and complex existing Offender Management code being impacted by the new solution, should, where possible, be deployed early in the Project. • Deliver customized functionality to CDCR in incremental pieces that are in logical business application sequence. • Include a deployment schedule developed in cooperation with CDCR that ensures continuous, uninterrupted Offender Management support throughout the project. The Bidder must submit a sample Implementation Plan with their proposal response as identified in Section VIII – Proposal and Bid Format. Bidder Response Detail: Appendix L contains a sample Implementation Plan that is representative of the actual Implementation Plan Team EDS will provide to CDCR for the SOMS project. The sample plan, drawn from Team EDS’ successful CalWorks Information Network (CalWIN) project, illustrates the structured approach Team EDS will take on the SOMS project. Working with the CDCR Project team from the start of the project, Team EDS will comply with the requirements outlined in RFP Requirement M-57 and adjust the plan as needed to clearly document a detailed Implementation Plan. As we have explained, our tracks-based organizational approach to implementing SOMS assigns highly skilled technical staff to focus on specific implementation activities, such as interfaces, data conversion, and data bridging. As a result, we can “flesh out” issues associated with technically challenging aspects of SOMS as early as possible; for example, determining a cutover approach early in the project identifies the technical and procedural challenges of coordinating data conversion with the cutover to new software. As we EDS SOMS STATEMENT OF WORK EXHIBIT I-12
  8. 8. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE mentioned in Section 4.2, Phasing, the sequence of functions delivered in individual software releases conforms to logical dependencies and provides for incremental delivery of SOMS functionality. Team EDS will work closely with CDCR project staff to adjust and confirm functional makeup of software releases and the associated deployment schedule. Our team will support functionality provided through each individual release, including all system interfaces, reports, and data bridges until the official closing of the entire SOMS project. As we describe in Section 4.2.D.3, Impact on State Resources, Team EDS will work with CDCR to designate one SOMS project liaison and one backup at each site. Team EDS will engage institutional liaisons throughout the SOMS project, with the liaisons serving as key points of contact to coordinate on-site activities with Team EDS. Based on our experience in other states, we anticipate institutional liaisons will need to allocate four to six hours a week to assist with the SOMS project; however, in the week before and after implementation of each release, institutional liaisons must allocate approximately half of their work time to the SOMS project. During these brief implementation windows, Team EDS will station implementation staff to work alongside institutional liaisons to foster smooth implementation of the release. Similarly, to prepare for rollout of parole functions, CDCR must designate a liaison for each parole office to assist the Project team with implementation activities. VI.D.9.b.Capacity Planning Requirements Req. Requirement Response / Reference Num. M-58 The Contractor shall develop a Capacity Plan (in coordination with Vol 1 – Appendices the existing DTS Capacity Plan) to include, at minimum, the Appendix K, following areas: Section 5.0 • A description of how system capacity and capacity requirements were calculated, including all formulas and calculations used in capacity planning for SOMS. • A description of how SOMS capacity requirements will be met. • How capacity issues will be managed for all components of the SOMS project. • Descriptions of how capacity utilization will be monitored and capacity thresholds will be established. • A description of corrective and escalation processes that will be used in the event any capacity thresholds are reached. Bidder Response Detail: As a world leader in infrastructure and system management, EDS brings to the SOMS project a wealth of capacity planning experience and technical resources. Our team will provide CDCR with a capacity plan that is fully coordinated with Department of Technology Services (DTS) standards and guidelines and that meets all requirements specified in RFP Requirement M-58. Appendix K contains a sample Capacity Plan drawn from EDS’ CMIPS II project, and Appendix L contains a sample Implementation Plan from our CalWIN project. EXHIBIT I-13 EDS SOMS STATEMENT OF WORK
  9. 9. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE The Capacity Plan we submit to CDCR is tailored specifically for the SOMS project; it describes our detailed approach to determining capacity and explains how our team sets performance and capacity thresholds, monitors utilization levels, and provides procedures and timelines for resolving or upgrading capacity. EDS will work jointly with CDCR and DTS to create procedures for escalation in the event that capacity planning forecasts indicate a need for system expansion. Our capacity planning activities forecast server, storage, and network resource requirements for hosting each SOMS release to objectively anticipate how the applications will perform before they are put into production. These activities help us to match the appropriate server, storage, and network sizing to system needs and make the most efficient use of resources. Effective capacity planning avoids capacity shortages as well as costly underutilization of resources. Our capacity planning and evaluation take the following into consideration: • The system’s architecture, related best practices, and product vendors’ relevant sizing models for systems following standard architecture, design patterns, and load conditions • Performance and scalability models gathered from tests executed • General system requirements, such as target response time • Concurrent number of users, transaction volumes, usage scenarios, and trends • Availability requirements • Data volumes • Growth factors for both usage and data. EDS will conduct performance tests of the SOMS releases not only to validate the performance of each release, but also to provide metrics to feed the SOMS capacity plans to forecast impact on the production environment. While conducting performance tests, we collect a wide variety of infrastructure metrics through our performance testing tool, HP LoadRunner, and use them as inputs for our capacity planning tools. The initial SOMS infrastructure architecture defined in this proposal was created in this manner, using information gathered from our benchmarking exercise of the proposed offender management COTS product in conjunction with other sizing information. Once in production, the SOMS Enterprise Monitoring System (EMS) provides an additional source of information for the project’s capacity planning models. The SOMS EMS includes Computer Associate’s eHealth, a tool that collects utilization information about servers, network components, storage, database, and application servers through real-time agents deployed systemwide. eHealth provides a centralized data store for SOMS performance metrics. Over time, eHealth creates a baseline of expected utilization levels for each system component, which automatically alerts the SOMS infrastructure staff if system metrics are not within an expected range. Acceptable levels of utilization are defined by individual component, based on industry standard practices; for example, a server may be considered saturated if operating at levels above 80 percent utilization for extended periods of time, whereas a network circuit may have a lower acceptable utilization level due to performance degradation considerations. In addition, eHealth includes patented algorithms to forecast EDS SOMS STATEMENT OF WORK EXHIBIT I-14
  10. 10. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE individual component utilization into the future to allow proactive remediation of resources before users are affected. Section 5.0, Technical Requirements Response, provides additional information about our use of the EMS toolset. EDS’ SOMS solution deploys capacity and performance monitoring components early in the project to support the onset of document scanning operations and data conversion efforts. Early deployment of infrastructure components enables monitoring of system utilization as SOMS functionality is incrementally added to the system with each software release. Early deployment, combined with our proposed phased approach, facilitates early detection of additional capacity needs before users are affected. In addition, our phased approach also fosters the ability to validate our design early in the process, which reduces project risk. One of the important outputs of our capacity planning activities is a proposed deployment architecture together with sizing estimates for servers, storage, and network bandwidth. Provided that the input data is fairly accurate in creating a realistic picture of the system under normal production setup, this exercise should provide CDCR and DTS with an accurate sizing estimation for various computing capacities (servers, storage, and network). Our tracks-based approach assigns infrastructure management as a separate track within the Delivery team. As a result, system architects and technical experts focus on system capacity issues from the start of project, establishing the system infrastructure and exposing technical challenges as early as possible in the project. VI.D.9.c. Operational Recovery Requirement Req. Requirement Response / Reference Num. M-59 Disaster recovery requirements relative to the physical systems Vol 1 – Appendices and planning for recovery from operational failures are not the Appendix F responsibility of the Contractor. However, the Contractor’s knowledge of the system solution will be helpful in CDCR’s business continuity and disaster recovery planning. The Contractor shall develop an Operational Recovery Plan that addresses the following: • The SOMS solution will ensure 99.99% availability. • Areas of the SOMS system most susceptible to failure or disaster that would result in downtime. • Recommendations for system recovery processes, or steps to take in the event of a downtime event. • Recommendations for CDCR on how to comprehensively and effectively mitigate the risk of a downtime event. • Recommendations for securing the system during a period of emergency operation. Bidder Response Detail: To aid CDCR with business continuity and disaster recovery (DR) planning, Team EDS will provide CDCR with an Operational Recovery Plan that meets the requirements specified in EXHIBIT I-15 EDS SOMS STATEMENT OF WORK
  11. 11. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE RFP Requirement M-59. We provide a sample Operational Recovery Plan in Appendix F of our response. Team EDS’ Business Continuity and DR approach builds on industry leading practices, which we draw both from our own experience of serving similar governmental entities and from standards adopted by groups such as the Federal Financial Institutions Examination Council (FFIEC) and the two DR certifying groups, Business Resilience Certification Consortium International (BRCCI), Certified Business Resilience Professional (CBRP) certification and Business Continuity Institute (BCI certification). Managing business continuity and DR requires a careful balance of prevention, readiness, and recovery strategies and procedures. The following table, Table 6.6-1 Basic Approach, outlines the basic steps of our approach. Table 6.6-1 – Basic Approach Recovery Requirements Risk Prevention Definition of availability and recovery Proactive measures intended to reduce the risk of requirements for essential business functions threat occurrence and the likelihood of invoking and processes of an organization, and the recovery plans. resources and services required to support them. Recovery Preparedness Recovery/Restoration Proactive measures should also help ensure that Arrangements and procedures that are verified and recovery procedures and arrangements will work held in readiness to recover essential business efficiently and effectively if recovery plans must functions and processes and the critical support be invoked. services, facilities, resources, and equipment on which they depend. EDS embraces the best practices and recommendations of the Information Technology Infrastructure Library (ITIL) across all aspects of service delivery and support. The ITIL incorporates information technology (IT) operational recovery, which is addressed within what ITIL terms IT Service Continuity Management. In delivering the Operational Recovery Plan, which forms a part of CDCR’s overall Business Continuity Plan, we draw extensively on our ITIL expertise and experience. Figure 6.6-3, IT Service Continuity Process Map, outlines the EDS top-level process map for IT service continuity management, compliant with ITIL. EDS SOMS STATEMENT OF WORK EXHIBIT I-16
  12. 12. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE Manage ITSCM Plan ITSCM Initiated Escalation Exercise / Execute Exercise of ITSCM Plan ITSCM Plan ITSCM Plan Updated Necessary Schedule & RFC Execute Prepare Requested ITSCM Plan Exercise Updates to Perform Identify ITSCM Plan Develop, Maintain & ITSCM Restoration Implement ITSM Plan Exercise Activities Minim um Perform Analysis & ITSCM Service Exercise Level Determine Impact Analyze & Docum ent Results Restored Schedule ITSCM Plan Time Trigger Time Trigger Update & Approve ITSCM Strategy & Plan Measure & Manage Risks ITSCM Assessment Change Execute Change Perform ITSCM Incident Required Closed ITSCM Plan Managem ent Awareness Management Change ITSCM Change Change Managem ent Change Management Assessment Management Completed Managem ent Process Result or Time Trigger Linked Process Activities Figure 6.6-3, IT Service Continuity Process Map In conjunction with the DR and business continuity planning, the Operational Recovery Plan takes into consideration the potential business impact of SOMS service interruptions and underlying risks. The Operational Recovery Plan addresses the following: • Areas of SOMS most susceptible to failure • Manual work-around procedures (required in the short term if system failures occur) • Prioritization of the operations to be maintained and how to maintain them • Recommendations for system recovery processes and the steps required to put the operational recovery procedures into effect • Documentation of the actions and the activities needed to resume business • Identification of mission-critical business processes and recovery requirements • Recommendations of actions to reduce risk during a downtime event • Recommendations for securing SOMS during emergency operations. EXHIBIT I-17 EDS SOMS STATEMENT OF WORK
  13. 13. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE VI.D.9.d.Interface Management Requirements Req. Requirement Response / Reference Num. M-60 The Contractor shall describe the interface management N/A approach and methodology used for the SOMS Project. The Bidder must submit a narrative describing the interface management approach and methodology with their proposal response as identified in Section VIII – Proposal and Bid Format. Bidder Response Detail: Team EDS employs a structured, end-to-end approach to developing and administering interfaces. Our success-proven approach to interface management is founded on: Interface Governance Optimal management of interfaces begins with our tracks-based alignment of work activities, whereby we establish a team dedicated solely to interface development and administration. The Interface track consists of a track lead, EDS subject-matter experts (SMEs), developers, and testers and encompasses the following: • Finalizing interface requirements • Defining interface specifications and protocols • Verifying and finalizing interface specifications • Building interfaces • Developing interface test scripts • Testing internal interfaces • Testing pilot interfaces with partners • Updating user and technical documentation. The Interface track lead assigns SMEs to work with external agencies to open channels of communication and to document laws, policies, and security requirements governing interfaces. In the course of defining a Statement of Work (SOW) for each interface, SMEs establish Inter-Agency Agreements (IAAs), Memorandums of Understanding (MOUs), and Service Level Agreements (SLAs) that clarify responsibilities between the organizations and define the protocol for identifying, escalating, and resolving interface issues. The Interface Management Plan describes protocol for Team EDS to prepare and present a draft of each MOU, IAA, and SLA and interface SOWs to CDCR’s SOMS Project team. The CDCR SOMS Project team will then be responsible for securing signoff of the agreements before our team implements the interface. While SMEs are defining the business context for interfaces and securing formal agreements, interface analysts assigned to the interface track work with CDCR staff to document existing interfaces and leverage sophisticated tools to discover, map, and document existing interfaces and application programming interfaces (APIs). Thus, EDS SOMS STATEMENT OF WORK EXHIBIT I-18
  14. 14. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE our tracks-based approach allows specialists to focus their expertise on the detailed tasks associated with constructing interfaces, while the track lead works collaboratively with other track leads, orchestrated by the implementation manager, to coordinate requirements definition, testing, implementation, and operating interfaces. During Phase 0 of the SOMS project, the Interface track lead finalizes an Interface Management Plan that is tailored to CDCR’s specific operational and technical requirements. The purpose of the Interface Management Plan, as we explain in our response to RFP Requirement M-62, is to establish guidelines for developing and managing interfaces, during the SOMS project and beyond. A second Phase 0 objective for the track lead is to create for the Interface team a Responsibility Assignment Matrix, which outlines specific task responsibilities and deliverables for team members. With many years of experience in integrating complex, disparate systems in a number of technical environments, Team EDS is well positioned to meet CDCR’s interface requirements. For example, EDS’ integration and service-oriented architecture (SOA) methodology is a state-of-the-art “body of knowledge” built over the past 14 years and using cutting-edge technologies and best-practice techniques. Our corporate methodology includes planning, execution, and monitoring of activities that provide consistent, repeatable procedures for our team to efficiently manage interfaces while mitigating risks to the SOMS project. The phases of interface management, from definition through operation, together with specific activities and key deliverables, are shown in the following tables: Table 6.6-2 – Integration and SOA Methodology Phases Integration and SOA Methodology – Define Phase High-Level Activities Develop the Integration Plan Gather integration and SOA requirements Develop the Metrics Plan Determine the interface identification approach Establish a Communication Plan and channels Gather user-centered design requirements with interface owners Establish SLAs and MOUs Establish governance and security policies Key Deliverables Integration Plan Communication Plan Metrics Plan Integration and SOA Requirements Definition EXHIBIT I-19 EDS SOMS STATEMENT OF WORK
  15. 15. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE Integration and SOA Methodology – Analyze Phase High-Level Activities Assess the current environment Inspect existing applications: data mine source Identify critical success factors and risks code, data structures, database schemas, existing interfaces, data extracts, and business Identify and prioritize key interfaces and rules services Identify standards, protocols, access channels, Identify candidate services laws and policies governing the interfaces Develop services recommendation Develop an Interface Partner Education Analyze artifacts from Team EDS’ past and Strategy and Plan current offender management Customize and conduct Interface Partner implementations Questionnaire Conduct Joint Application Design (JAD) Develop interface partner profiles sessions with CDCR’s technical services group for existing applications with CDCR SMEs Perform a gap analysis Define Test Plans and Test Cases Key Deliverables Current Environment Assessment Test Plans and Cases Gap Analysis Service Identification and Definition Report Integration and SOA Methodology – Architect Phase High-Level Activities Validate requirements Develop a Bill of Materials Identify alternative solutions Develop an Integration and SOA Governance Develop the logical architecture Model Develop the technical architecture Define the Technical Solution Road Map Develop the physical architecture Key Deliverables Technical Solution and Road Map Bill of Materials Governance Model Integration and SOA Methodology – Design Phase High-Level Activities Validate interface and service requirements Design the business activity monitoring Design the security implementation implementation Develop integration specifications Develop contingency plans Design services interfaces Design services management Design transformations and service assemblies Define operational support specifications Design the business rules implementation Develop test specifications Key Deliverables Integration and SOA Technical Design Development Environment, Processes, and Configuration Management Plan Procedures Services Design and Development Specifications EDS SOMS STATEMENT OF WORK EXHIBIT I-20
  16. 16. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE Integration and SOA Methodology – Produce Phase High-Level Activities Configure and install the development and unit Build business rules test environment Build business activity monitoring Build and document the integration solution Develop services management Develop services Build end-system simulators Apply security policies Perform unit testing Build the enabling application services Develop operations support documentation Publish services Key Deliverables Development/Unit Test Environment Test Case Results Developed Solution Operations Support Guide Integration and SOA Methodology – Optimize Phase High-Level Activities Develop Integration Test Plans, data, and Conduct load and stress testing scripts Update registry status Configure and install the integration test Develop end-user and Operations Training environment Plan Implement version control and configuration Execute end-user and operations training management Refine operations support documentation Execute system test cases and scripts Key Deliverables Integration and Services Test Environment Completed End-User and Operations Training System Test Plans and Cases Results Integration and SOA Methodology – Implement Phase High-Level Activities Conduct knowledge transfer from the Monitor production performance and support development staff to production support problem corrective action personnel Evaluate and improve integration and SOA Develop the Production Implementation Plan intellectual capital Install and configure the production Perform project close-down environment Migrate the solution to the production environment Key Deliverables Production Environment, Processes, and Project Completion Documentation Procedures Software and Procedure Updates EXHIBIT I-21 EDS SOMS STATEMENT OF WORK
  17. 17. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE Integration and SOA Methodology – Operate Phase High-Level Activities Perform transformation management Develop minor enhancements Monitor integration operations and services Perform minor software upgrades Perform incident management Perform release management Perform problem management Perform close-down Key Deliverables Transitioned Support Processes Managed Integration and SOA Environment Integration and SOA Operations Reports In addition to our structured approach toward interface management, our COTS solution is uniquely equipped to meet CDCR interface needs promptly. The current generation of our COTS offender management system has been implemented in corrections departments in three states. As a result, our COTS solution contains many interfaces that are common to state corrections departments. For example, the electronic Offender Management Information System (eOMIS) currently provides an interface to the Social Security Administration (SSA), the Department of Homeland Security (DHS), National Prisoner Statistics (NPS), National Corrections Reporting Program (NCRP), U.S. Census, and the Association of State Correctional Administrators’ Performance-Based Measures System (PBMS). Moreover, many of the interfaces CDCR requires are similar to interfaces used in other states and are present in eOMIS. Using existing interfaces as templates, our team is able to rapidly deliver California-specific interfaces. Having implemented a large number of interfaces, in other state corrections departments and for the California State Government, our team will promptly overcome challenges unique to CDCR’s interface requirements. Section 4.2.H, Interfaces, highlights specific examples of our team’s successful implementation of interfaces and describes how it has overcome unique technical and organizational challenges. Two examples that are of strategic relevance to SOMS are the following: • A fully operational HL-7-based interface between eOMIS and healthcare providers for the State of Arkansas Department of Corrections. • A real-time Web services interface between the eOMIS inmate banking system and third- party canteen vendors for the State of Kentucky Department of Corrections. This interface has supported the agency’s business requirements of contracting to different canteen vendors at different institutions. Each canteen vendor interchanges data in real time through a single eOMIS interface. This strategy has enabled vendors to deploy order entry kiosks inside prisons, with each vendor’s kiosk directly updating the inmate banking system through the interface. Interface Technology: Architecture, Tools, and Standards Our technical architecture and software tools, which we describe in other sections of our proposal, are instrumental in achieving the goal of providing a stable, well-managed interface environment. Moreover, our awareness and compliance with State of California and EDS SOMS STATEMENT OF WORK EXHIBIT I-22
  18. 18. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE national data exchange standards positions CDCR to readily adapt to changing requirements by: • Using current existing operating interfaces, when appropriate • Leveraging open or industry standards, such as eXtensible Markup Language (XML), National Information Exchange Model (NIEM), Web Services, Simple Object Access Protocol (SOAP), WS*, HL-7, and File Transfer Protocol (FTP) • Reducing integration complexity through the enablement of SOA principles • Decoupling applications from each other by creating a layer of abstraction between interface points • Providing powerful and configurable transformation and routing capabilities • Allowing for an integration between systems that communicate using different protocols and mechanisms • Incorporating proven products, such as Oracle SOA suite and the Sypherlink National Information Exchange (NIE) Gateway and Harmonizer • Exposing commonly used services and data through an Enterprise Service Bus (ESB) to share services across the enterprise and to maximize efficient re-use of interfaces • Using the ESB to implement security rules, leverage pre-built interface adapters, and serve as a repository for interface documentation Our interface environment is based on SOA principles, enabled through an Oracle ESB that aligns with CDCR’s and the State’s vision for enterprise architecture. The ESB is positioned as the key integration component, and data exchanges are modeled using the NIEM specification. By creating a layer of abstraction between system components, the ESB eliminates the need for agencies exchanging data to have technical information about their counterpart’s system environment. Using a nationally recognized standard for data specification minimizes the level and complexity of programming involved in developing and implementing interfaces. Although the system architecture and NIEM compliance prepare CDCR to exchange data with agencies that are on the cusp of current technology, we realize that the majority of the systems with which SOMS must interface are not currently NIEM compliant. For those interfaces, we implement interfaces that interact within the technical limitations of the reciprocal system; for example, the California Law Enforcement Telecommunications System (CLETS) is a non-NIEM compliant, Transmission Control Protocol / Internet Protocol (TCP/IP) socket interface. Having constructed a National Crime Information Center (NCIC) in other states, Team EDS is prepared to implement a native interface according to California Department of Justice’s (DOJ’s) technical specifications. EXHIBIT I-23 EDS SOMS STATEMENT OF WORK
  19. 19. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE M-61 The Contractor shall incorporate the interface management Section 4.2.H, approach into a comprehensive Interface Management Plan. Vol 1 – Appendices The Interface Management Plan will be used by CDCR to Appendix M document the plan for integrating the SOMS System with all systems internal and external to SOMS. The Interface Management Plan shall, at a minimum, address the following areas:  The approach to developing and managing internal and external system interfaces.  Technical tools that will be used for data transformation, transport and error recovery.  Tasks, deliverables and resources necessary to complete interface development and implementation.  Description of how the SOMS development and test systems will work with the external interfaces.  References to applicable sections in the relevant design documents that describe how the SOMS system will be synchronized with the specific internal and external interfaces.  References to applicable sections in the detailed design that describe the mappings between internal and external system data and the SOMS system data.  Descriptions of the process for managing changes to the interfaces, both in the production and non- production environments  Interface(s) needed for maintaining data synchronization between an interim production solution and the final production implementation. The Bidder must submit a sample Interface Management Plan with their proposal response as identified in Section VIII – Proposal and Bid Format. Bidder Response Detail: The methodology we have described here and in Section 4.2.H, Interfaces provides the baseline approach for Team EDS’ developing and managing SOMS interfaces. Section 4.2.D, Phasing, and Section 4.2.H, Interfaces, of our proposal detail our implementation approach and the interfaces associated with each SOMS release. To gain a better understanding of the intricacies of each interface, our team will work with CDCR staff, technical support staff from Enterprise Information Services (EIS), and CDCR SMEs, who are knowledgeable about the business context of individual interfaces. With our sophisticated tools and our team’s experience, we anticipate relatively minimal CDCR staff involvement. For each interface, we anticipate from 1 to 6 hours of CDCR staff involvement during the initial Definition phase. Throughout each phase of interface development, our team will involve CDCR, but will require minimal allocation of CDCR staff time. As part of interface implementation, CDCR staff will be called on to disengage existing interfaces from the legacy environment as EDS SOMS STATEMENT OF WORK EXHIBIT I-24
  20. 20. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE required. As the project enters the Maintenance and Operations (M&O) phase, EDS staff will provide technical training to equip CDCR staff to take over interface maintenance duties at the close of the project. Appendix M contains a sample Interface Management Plan from our CalWIN project. The Interface Management Plan, which EDS will submit to CDCR, will be customized to specifically address governance procedures and technical standards for SOMS interfaces. At a minimum, our Interface Management Plan will include the following topics: Interface Management and Governance Protocol for Initiating an External Data Exchange / interface The Interface Management Plan defines the official protocol, consistent with CDCR policy, to establish a recurring exchange of data and connectivity between SOMS and external entities. The guidelines specify information required from external parties to initiate an interface; for example, the Interface team documents the business context for the interface from the perspective of both CDCR and the external entity, how frequently the information must be updated, anticipated security requirements and provisions, and data privacy considerations. The purpose of this section is to establish formal governance and control over the proliferation of interfaces, with the goal of structured development and administration of interfaces and data exchanges. Protocol for Initiating Internal Data Exchanges and Interfaces The integrated nature of our COTS solution, and the reporting, business intelligence, and portal components of SOMS, significantly reduces the need for new interfaces among CDCR business units. Users with appropriate security authorization, with support from the help desk, will be capable of generating extract files and importing data into desk top software without involving EIS staff; however, introduction of new third-party software may warrant new interfaces into and from SOMS. The guidelines outline information to be documented, including business context and security or data privacy considerations. Interface Scope and Service Agreements The Interface Management Plan provides a checklist of requirements for collecting necessary information and agreements. EDS staff will comply with these guidelines to document business requirements, an interface SOW, policies and laws relevant to the interface, security and data privacy requirements, and formal agreement as warranted by the interface. This section of the Interface Management Plan prescribes criteria for when MOUs, IAAs, and SLAs are required and CDCR’s approval process. The Interface Management Plan treats MOUs, IAAs, and SLAs as formal, official documents to be managed in the same manner as Agency contracts in accordance with CDCR policy. The section also contains MOU, IAA, SLA and scope-of-work templates to foster standardization and to minimize administrative burdens. Procedures for Maintaining a Library of Interfaces The Interface Management Plan describes procedures and requirements to properly document all new interfaces, together with change management provisions. Team EDS will EXHIBIT I-25 EDS SOMS STATEMENT OF WORK
  21. 21. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE comply with these guidelines to establish a repository of all interfaces built for SOMS. Each interface will be fully documented, including business and technical documentation, all of which will be maintained within the ESB infrastructure. Detailed information includes source and target systems and their respective environments, file formats, data mapping and transformation rules, exchange protocols, security rules, data and file replacement and cessation rules, references to program libraries, objects, and source code, points of contact, and escalation and notification rules. Business context, such as copies of SLAs, MOUs, and IAAs, are maintained in the Interface Library. Information from the various sources is reconciled to promote accuracy, completeness, and security of SOMS interfaces. Interface Communication Plan A subsidiary to the overall Project Communication Plan, the Interface Management Plan outlines procedures for communicating new interfaces, revisions to interfaces, security alerts and breaches, and general issue notification procedures. This section also describes procedures for notifying administrative staff of issues, database changes, and protocol for requesting interface revision. Interface Change Management A subsidiary of overarching SOMS change management, the Interface Management Plan describes interface change management procedures; for example, the section describes procedures for executing and monitoring changes to interfaces and for itemizing components that are interdependent with interfaces. Interface Technical Guidelines System environment The Interface Management Plan provides technical information needed by staff engaged in developing and administering interfaces. Examples of information included in this section include database schema; NIEM-compliant data definitions; Information Exchange Package Documents (IEPD); SOA components; the Justice Reference Architecture; specifications and references for ESB usage; security and authorization provisions; and an inventory, description, and reference for all software tools employed in existing and planned interfaces. This section also defines the platforms used to develop interfaces, the test platforms, quality assurance (QA) and pre-production platforms, and the production platforms that will ultimately host interfaces. As a subsidiary to the Configuration Management Plan, this section documents the entire technology stack of all platforms. Development and Testing Procedures The Interface Management Plan describes technical guidelines and programming conventions for development of interfaces, including procedures for data discovery, “mining” of system rules, and data mapping protocols. The guidelines also present samples and descriptions of the artifacts required from each of the interface activities (analyze, design, develop, optimize, implement, and operate). The testing portion of the Interface Management Plan, as an adjunct to the overall Test Plan, dictates mandatory unit and system testing, QA procedures, and migration procedures specific to interfaces. The Interface Management Plan includes an appendix with examples of test environments that EDS SOMS STATEMENT OF WORK EXHIBIT I-26
  22. 22. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE simulate external and reciprocal systems, lessons learned from interfaces that have been implemented, and guidelines for testing external systems. Documentation Requirements The Interface Management Plan describes the information interface analysts are required to submit to the Interface Library and associated change control provisions. Interface and Reciprocal System Audits and Synchronization The Interface Management Plan describes procedures, time frames, and staff responsibilities related to periodic auditing of system interfaces. Audit provisions focus on security and data privacy concerns as well as assessment of data integrity. In the Interface Library, each interface includes a definition of data audit requirements and, when applicable, data synchronization provisions; for example, in the event that an interface audit reveals that a reciprocal system that replicates data from SOMS transmissions has become corrupted, the Interface team follows procedures for escalating the problem and taking corrective action, which may involve resynchronization of data in accordance with the specified synchronization guidelines. Interim Interfaces The Interface Management Plan addresses requirements, techniques, and provisions for implementing interim bridges in the course of implementing SOMS phases. Provisions for interim bridges address documentation, testing, and implementation procedures with a focus on relationships between SOMS and legacy system environments, data accessibility, and reporting provisions. M-62 The Contractor will identify any legacy modifications Section 4.2.E required for the new SOMS System and external systems to exchange data, and CDCR will be responsible for implementing requested legacy software changes. Bidder Response Detail: Our implementation approach rolls out SOMS incrementally in phases to minimize impact on CDCR operations and users. A key strategy for incremental yet transparent rollout of SOMS involves transmitting data from SOMS back to legacy systems to enable these systems to continue to function until the entire legacy system is retired. In the first SOMS release, Reception Centers will enter inmate records for new intakes into SOMS instead of into the Offender-Based Information System (OBIS). Because not all components of OBIS will be replaced in Release 1A, we implement an interim bridge with this release, by which we transmit data for new intakes from SOMS to OBIS. When the bridge is implemented correctly, users of OBIS do not realize that the record was not created in the usual manner, and all “downstream” functions operate “as is.” Team EDS will work closely with CDCR technical staff to develop interim bridges between SOMS and CDCR’s legacy systems. Our team takes full responsibility for developing interim bridges, but will depend on CDCR technical staff to install the bridges into legacy systems EXHIBIT I-27 EDS SOMS STATEMENT OF WORK
  23. 23. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE and to assist in testing the bridges. As with all interfaces, our team will need as much information as possible about the target system. To the extent possible, bridges from SOMS into legacy systems will use file formats and data exchange mechanisms of existing interfaces to avoid the need to develop custom bridges into legacy systems. Team EDS will develop a bridge with administrative assistance from CDCR staff when no interface into the target system exists (as is the case with OBIS). An additional complicating factor of which our team is aware is the fact that certain legacy systems, such as the Distributed Data Processing System (DDPS), are distributed in multiple locations; consequently, installation of interim bridges into such systems will involve on-site or remote access and thorough testing with individual iteration of the legacy application. Our implementation approach minimizes the need for changes to CDCR legacy systems; however, each SOMS release retires components of legacy systems, but not always the entire system. For components of legacy systems that are replaced by a SOMS release, CDCR staff, with assistance from EDS, will “disable” data updates into the replaced component. Release 1A, for example, replaces the Inmate Number Assignment component of OBIS. To avoid data integrity problems, for Release 1A, EDS will work with CDCR to “disable” Inmate Number Assignment from the OBIS system, while leaving other parts of OBIS unchanged. We have tentatively identified four legacy applications, OBIS, DDPS, the Corrections Institutions Information Management System (CIIMS) and the Automated Transfer System (ATS), which may require modification to support data bridges. Section 4.2.E, Data Conversion, includes an explanation of how SOMS releases will affect these applications under the heading, “Transitioning to SOMS.” Throughout the course of the SOMS project, EDS will partner with CDCR to comply with the requirements set forth by RFP Requirement M-62. VI.D.9.e. Data Conversion Requirements Req. Requirement Response / Reference Num. M-63 The Contractor shall describe the data conversion approach Section 4.2.E and methodology used for the SOMS Project. The Bidder must submit a narrative describing the data conversion approach and methodology with their proposal response as identified in Section VIII – Proposal and Bid Format. Bidder Response Detail: Team EDS will employ a structured, time-tested approach to data conversion. Our data conversion methodology is based on best practices that we have acquired from our many data conversion engagements. In addition to our proven approach, our team has direct experience of migrating data from Legacy Offender Management applications into eOMIS, the COTS solution we deploy to meet SOMS objectives. Specifically, our team has successfully managed the conversion of legacy data from multiple sources into eOMIS for the Department of Corrections in the States of Arkansas, Kentucky, and Wisconsin. Team EDS has also successfully delivered data migration services to multiple government entities in more than a dozen states, including the State of California, across various business EDS SOMS STATEMENT OF WORK EXHIBIT I-28
  24. 24. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE verticals, such as Motor Vehicles, Elections, Unemployment, Retirement, and Public Health. Our former clients are willing to testify to the effectiveness of our data conversion approach and our dedication to providing business continuity throughout the transition process. A cornerstone of our data conversion approach is our tracks-based alignment of work activities across the project. Because data conversion efforts are essential to the success of the SOMS project, our tracks-based approach dedicates a complete track to the data conversion effort. This dedication provides visibility, focus, and expertise in completing data conversion within the timeframe required by the SOMS project. To manage all aspects of the data conversions, our data conversion track lead will apply EDS’ System Development Life Cycle (SLC3) methodology within the framework of our Global Application Delivery-Quality Management System (GAD-QMS), both of which we describe in Section 6.0, Management Requirements of our proposal. Combining these structured methodologies in conjunction with our tracks-based organization of staff mitigates risks and provides the framework for project success. Our approach to data conversion is founded on a combination of technology, experience, expertise, and project management methods. Although each project will vary depending on the source and target, a solid set of practices will make sure each incremental data conversion is successful. Throughout the SOMS project, our Data Conversion team will adhere to the following principles and guidelines: Clarify and Document Conversion Objectives Our team will begin data conversion activities by documenting the objectives of the undertaking. We focus on migration requirements; potential risks and obstacles, such as multiple locations of source data; and business context related to the effort. Collaborate With CDCR Partnership and collaboration are essential to the conversion effort. For each release, our data conversion track lead coordinates activities with the implementation manager and maintains close communications with CDCR staff involved in data conversion activities. To meet the required timeframe, CDCR will have to designate technical points of contact (POCs) for each legacy environment. Our data conversion analysts work directly with technical POCs to gain a rapid understanding of the legacy environment, business rules, constraints, and challenges. CDCR SMEs will also be instrumental in providing business context associated with each legacy system. Team EDS knows from experience that open communication, such as frequent reviews, is a major factor in early identification of potential problems. CDCR staff will be responsible for providing access to needed data from legacy systems that will contribute data to the SOMS database. Team EDS may need to access the data directly from the legacy system or from a mutually agreed upon extraction process. Our approach minimizes, to the extent possible, the burden on CDCR staff; however, we require the following support from CDCR SMEs and technical POCs: • Validation of record counts of data extracted and converted to SOMS. EXHIBIT I-29 EDS SOMS STATEMENT OF WORK
  25. 25. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE • Assistance to assess the impact that multiple locations of source data has on the data conversion. Team EDS will work with CDCR staff to determine the optimum approach for resolving issues associated with the existing dispersion of legacy data across CDCR locations. • Assistance to designate the system of record for data that resides in multiple legacy systems. • Assistance to verify data element mapping that is generated by the automated mapping tool set. The automated data analysis and mapping tool will complete the majority of the mapping between the source and target data elements; however, because of the diverse sources of the data and the differences in database structures, some mapping will require human intervention. The SMEs will work with Team EDS to refine mapping decisions that cannot be resolved by the automated mapping tool. • SME assistance for Team EDS to define default values and business rules to populate such fields because it is unlikely that all data elements defined to SOMS will exist in the legacy systems. • SME assistance to relate required legacy code values to SOMS code values, which are National Crime Information Center (NCIC) code value standards. These relationships are recorded for use in automated conversion and interface processes. • SME assistance to define the business rules needed to consolidate data under a single offender ID because the source data is known to contain the same offender stored under multiple offender IDs; for example, an offender may have been incarcerated multiple times with a new offender ID each time. In addition, addresses may have been entered multiple times. Business rules will also be developed in an effort to remove as many duplicate addresses as possible. • Assistance in defining, reviewing, and refining data transformation rules. • Assistance to review error reports to determine the action to be taken to correct errors. The solution may result in legacy data being corrected or the transformation business rules may be altered to eliminate the error. • Validation of conversion results. Maximize Use of Technology for Accuracy and Productivity Typically, data conversion is a labor intensive undertaking involving manual efforts to investigate source systems to map data into the new target database. Such a manual approach requires repeated iterations as each field within a file or database is analyzed and traced. To ramp up the productivity of the Data Conversion team, our approach will deploy state-of-the-art, patented automated data migration technology, such as the Sypherlink Harvester. Our team will use the Harvester suite of tools to automate database interrogation, data discovery, cross referencing data within source systems, and high level mapping of data from source systems into eOMIS. These tools include powerful extract, transform and load (ETL) tools as well as the advanced software for source data consolidation. Team EDS estimates that the use these tools accomplishes as much as 70 percent of data discovery and mapping. The migration process will still require multiple iterations, but the automation tools will speed the process dramatically. Each iteration will add to our knowledge of legacy data to incrementally increase our team’s productivity. Team EDS SOMS STATEMENT OF WORK EXHIBIT I-30
  26. 26. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE EDS will use this growing knowledge base to refine the conversion process by using standard change management practices. Insulate the Data Conversion Environment Team EDS will create a development environment specifically for the conversion process. Because of the iterative nature of the conversion process, we perform this work in a separate environment to avoid interference with SOMS development, testing, and training efforts. This environment also provides a single repository for legacy data to be brought together from the various sources, which is essential for the mapping and transformation processes. Maximize Reuse of Software Our technique for developing programs for the ETL of data from a source system into eOMIS takes a modular approach that maximizes code reuse. Our modular design methodology will enable developers to build standard templates for similar mappings to achieve faster and more accurate development of modules. Team EDS’ reuse strategy saves time, money, and resources and lowers total project cost. Opportunities to collect reusable data are high during conversion projects. Focus on Data Accuracy Most of the data mapping and transformation process will be performed successfully through use of the automated tool sets Team EDS provides. As discrepancies are uncovered, we add new data quality rules using Team EDS’ Data Conversion methodology. Throughout the data conversion, we locate data exceptions and create rules to correct them. Creating a common process for collecting these exceptions will provide guidance to the Conversion team and easy reference for CDCR. We document such data exceptions and confirm our mitigation strategy with CDCR project representatives. Perform Data Governance Data Governance activities define the business rules for dealing with data that exists in more than one legacy source system. These rules guide SMEs with a framework for decision- making and indicate how to manage data. Data Governance policies are a necessary step in the conversion process because they remove uncertainty at a high level. By completing an accurate set of Data Governance policies, CDCR will achieve a significant scope clarification that provides insight throughout the project. Data Conversion Phases Team EDS’ overall data conversion approach entails progression through seven distinct phases. Each phase has clear processes, tasks, and deliverables, which we identify as follows. Discovery Phase The Discovery phase consists of documenting the existing “baseline” or “as-is” environment across CDCR’s disparate systems. This critical – yet often underestimated – initial step is the effort involved in discovering, documenting, and analyzing baseline data sources. The scope EXHIBIT I-31 EDS SOMS STATEMENT OF WORK
  27. 27. EDS AGREEMENT NUMBER [XXXX] CALIFORNIA DEPARTMENT OF CORRECTIONS AND REHABILITATION (CDCR) EXHIBIT I MANAGEMENT REQUIREMENTS RESPONSE of systems within CDCR is broad; therefore, to assist with our planning of an appropriate risk mitigation strategy, our approach will be to discover the following issues: • Coordination of baseline discovery efforts • Existing network connectivity environments • Poorly documented systems • Lack of subject-matter expertise • Lack of technical resources available at agencies • Lack of cooperation and support by system vendors • Time commitments required by individual agencies to accommodate the process. Discovery Phase Identify Acquire Contact Automate Learn Prioritize Determine all Obtain access to Establish a user Run Sypherlink Create an expert Determine what systems to be or backups from and technical Harvester on the source systems will be converted in the all required data point of contact Analyzer to system by data completed – and scope of the sources. for obtaining discover analysis and in which order – project. This information, if metadata schema understanding based upon the includes available, for and obtain data core application complexity and understanding each system. quality metrics functionality and criticality. the in-house or across all business rules. vendor-based systems. systems involved. Figure 6.6-4, Discovery Phase Mapping Phase The Mapping phase determines how field-level data corresponds to data within eOMIS. A key consideration of the overall time and cost associated will be the amount of effort required to map appropriate relationships from the more than 40 systems into eOMIS. Traditional mapping efforts rely heavily on the availability of SMEs, well-documented systems, and the human cognitive skills of the individual doing the mapping to identify where field-pair relationships exist. The result is a lengthy, laborious, error-prone, and costly mapping exercise. Traditionally, an individual will map from three to five fields an hour for each resource. Extrapolating this across the legacy systems, the cost impact becomes apparent. To effectively and cost-efficiently perform this mapping effort, Team EDS will leverage the Sypherlink suite of products to accelerate the process and improve the quality, time, and cost metrics. EDS SOMS STATEMENT OF WORK EXHIBIT I-32

×