DCFY DEPS Architecture Plan.pdf

DEPS ARCHITECTURE PLAN

HIGH LEVEL ARCHITECTURE ROADMAP

Dennis Kim Solutions Architect

December 2024 i

Table of Contents

DEPS Executive Summary

Business Context

Challenges with SSPS and Payment Ecosystem

Technology Challenges:

Data Challenges:

People & Process Challenges:

Project Timeline

Assessment Phase

Architecture Development Methodology

Business Context

Definitions of DCYF Payment Pathways

Step 0. Program Enrollment

Step 1. Service Authorization

Step 2. Payment Authorization

Step 3. Payment Processing

Reporting

DEPS Functional Requirements

System Context

Current State

Interface List

Planning Phase

Future State

Architecture Design Principles

Technical Standards and Preferences

Security

Summary of Functional and Non-Functional Requirements

Future DEPS Functional Requirements Summary ii

Architectural Refinements and Considerations

DEPS Non-Functional Requirements

User Experience Requirements

Audit & Compliance Requirements

Performance and Availability Requirements

Interoperability and Integration Requirements

Security and Access Controls Requirements

Business Continuity and Disaster Recovery Requirements

Solution Management and Monitoring Requirements

Notional Target State

Design and PoC

Implementation Phase

Environments

Migration Plan

Test Strategy

Go-Live Readiness

Maintenance and Operations

Deployment and Support

DEPS Executive Summary The Department of Children, Youth, and Families (DCYF) is a cabinet-level agency administratively created by Governor Inslee in 2017 with the goal of focusing on families and children to improve outcomes for at-risk families and youth. The creation of DCYF brought together several business functions that existed in the Department of Social and Health Services (DSHS) and the Department of Early Learning (DEL). Additional functions to support juvenile justice moved from DSHS to DCYF in 2019.

DCYF is the lead agency for state-funded services that support children and families to build resilience, health, and to improve educational outcomes. DCYF accomplishes this work by partnering with state and local agencies, tribes, and other organizations in communities across the state of Washington.

DCYF’s guiding principles are:

• A relentless focus on outcomes for children.

• A commitment to collaboration and transparency.

• A commitment to using data to inform and evaluate reforms, leveraging and aligning existing services with desired child outcomes.

• A focus on supporting staff as they contribute to the agency’s goals and outcomes.

DCYF is currently working to modernize the Social Service Payment System (SSPS) and associated payment authorization systems/processes through DCYF Enterprise Payment Solution (DEPS). DCYF aims to improve payment efficiency, accuracy, and transparency with the goal of ensuring that payment recipients (including vendors and service providers) receive timely and accurate response. This initiative is aligned with broader organizational objectives of enhancing system and process efficiency, complying with legislative and regulatory mandates, and making best use of technology where the risk-adjusted benefit is appropriate and substantial.

The purpose of this assessment is to determine the technical, operational and financial feasibility of DCYF’s preferred enterprise payment solution approach. DCYF followed a structured process to conduct this assessment, which consisted of the following steps:

1. Definition of the business and technical need for modernizing SSPS.

2. Definition of DCYF’s vision for a future-state enterprise payment solution.

3. Identification of goals, and objectives for the enterprise payment solution.

4. Analysis of the current and target payment solution business architectures.

5. Analysis of the business capabilities and business processes the enterprise payment solution is to enable and support.

6. Definition of functional and non-functional requirements for the enterprise payment solution and general system design.

7. Structured analysis of alternatives available to implement an enterprise payment solution and selection of a preferred solution alternative.

8. Comprehensive cost-benefit analysis of DCYF’s preferred enterprise payment solution, including all costs to design, develop and implement the enterprise payment solution and DCYF’s anticipated benefits directly resulting from the implementation of the solution.

9. When request for proposals are issued, the architecture will remain open for vendors to define and defend the approach they feel will best meet the needs of

DEPS.

10. Key similarities for each alternative:

Timelines for each alternative for both implementation and maintenance and operations (M&O) are identical.

Benefits are not specific to the alternative but to the value of DEPS.

Cost difference of 3% between the two alternatives ($5.5M).

Business Context The SSPS and associated payment authorization systems and processes are leveraged to administer payments to vendors, including foster parents, childcare providers, program service providers and other vendors of goods and services contracted by the agency. In total the agency administers over $800 million in payments. The systems and processes involve over 2,000 DCYF case workers and over 23,000 external service providers.

The pathways and systems currently used to administer payments are largely program-specific and have been brought over from DCYF’s predecessor agencies. In total, 57 different pathways and 25 systems have been identified in a Business Architecture Analysis.

Challenges with SSPS and Payment Ecosystem An environmental assessment of SSPS identified several challenges with medium-to-high likelihood of occurrence and medium-to-high impact to DCYF’s operations and reputation.

These include:

Technology Challenges:

• Legacy Unisys mainframe / COBOL system, a set of technology that is increasingly challenging to support from a skills and resource perspective.

• IBM mainframe for printing that is costly to maintain.

• Home-grown application and bolt-on applications on Windows Servers that is challenging and resource intensive to enhance to meet compliance requirements from state and federal funders and to meet DCYF business needs (e.g. – limitations in authorization dollar amounts and number of lines of service).

Data Challenges:

• Multiple and inconsistent identifiers for provider, vendor, client, entity and payee across the different systems in the payment ecosystem require manual processing to maintain and manage. This impacts DCYF’s ability to produce accurate payment and reporting information.

• Duplication of data in multiple databases.

People & Process Challenges:

• Manual processes due to technology limitations, lack of automation or common standards to facilitate use of technology across DCYF programs. This includes manual authorization of services, manual uploads, manual email notifications and approvals, manual creation and selection of service codes, and paper-based tracking.

• Challenges in training or cross-training DCYF staff across programs.

• Lack of formal disaster recovery process for SSPS and associated systems.

Project Timeline As part of the DEPS Planning effort, DCYF built an 8-year implementation project timeline that is scheduled to begin third quarter of 2025. Since DCYF is still in its planning and procurement phases, the project timeline, resources required, and key milestones in Section 9.0 (Estimated Timeframe and Work Plan) are driven by several assumptions that were agreed upon at the time of planning activities with DCYF DEPS team.

The project timeline spans 8 years, project years 6-8 include DEPS M&O only with the intent of DCYF taking responsibility of M&O over.

Phase 0: Procurement – which includes several months of procurement activities to acquire the required DEPS resources.

Phase 1: Implementation – which comprises three years of DDI activities. DCYF is using three years as a baseline and will be open to a shorter implementation period.

Phase 2: Maintenance and Operations (M&O) for five years after the system go-live date.

Assessment Phase The assessment phase comprises of the current state analysis required from the team to identify the state of the enterprise landscape and upcoming enhancements that may influence the target state of the DEPS solution. The landscape has been identified to be highly dynamic due to the continuous enhancements across the enterprise. Keeping this complexity in mind, the architecture development needs to be Agile in nature and be able to respond to changes throughout the lifecycle of the program. The following methodology enables continuous improvement in architecture throughout the program implementation lifecycle.

Architecture Development Methodology The program will follow the iterative architecture development where the guiding principles and core requirements influence the development of the architecture.

TOGAF® Standard —Architecture Development Methodology

The architectural documents will be structured in the following manner.

• The high-level architecture will be documented in an overarching “DEPS Architecture Blueprint” document.

• Individual solution designs that address functional and technical design areas will be managed separately and referenced in the blueprint as applicable.

Business Context The business architecture analysis of the DCYF payment toward payments.

There are four major DCYF programs and administration to understand the current pathways from eligibility to payment for goods and services.

https://pubs.opengroup.org/togaf-standard/adm/chap01.html#tag_01_02

Definitions of DCYF Payment Pathways

Step 0. Program Enrollment

• Determine Client Eligibility: Determine and confirm the client is eligible for DCYF services and there is a need for services.

• Acquire Service Providers: Acquire new service providers to provide services to

DCYF’s clients through methods including but not limited to applying to become a service provider, responding to a solicitation, etc.

• License Service Providers (Backgrounding): Initiate, complete, and/or renew the licenses of DCYF service providers. "Licensing includes Early Learning (EL) licensed childcare providers and Division of Licensing licensed foster care providers as well as backgrounding for license-exempt providers (Family, Friends and Neighbors).

This also includes completing activities related to ensuring that the service provider is a good fit for DCYF's Juvenile Rehabilitation (JR) program, including but not limited to ability to pass a thorough background check, ability to work in a carceral environment, and ability to demonstrate the appropriate motivations to work with DCYF's JR population.

• Contract with Service Providers: Manage the contractual agreements for DCYF’s service providers, includes various contract types e.g., service agreements as well as the statements of work (SOW)

• Manage Service Providers: Manage the activities of service providers, including monitoring performance and quality, managing provider capacity, and managing service provider access to systems (such as provisioning separate provider numbers to FamLink, SPSS and AFRS)

Step 1. Service Authorization

• Request Services: Request initiated by DCYF staff for a client to receive services;

May also be known as a service referral

• Authorize Services: Approve delivery of services to client by connecting clients with eligible service providers

• Provide Service Delivery Proof: Capture evidence of the services provided (e.g., attendance, receipts, voucher, provider invoices)

Step 2. Payment Authorization

• Confirm Services Provided: Perform matching of service delivery proof with the services authorized; Validate authorization and service codes provided

• Determine Rate and Payment Amount: Identify rates and determine payment amount based on service code and fee table

• Apply Account Coding Rules: Enter the appropriate program, function, object, and unit (Chart of Account elements such as SOF, Fund, Appropriation Index, Program Index, Sub Object Code, and Allocation Codes) provided to ensure funding rules are adhered to for the payment; Determine and apply the correct funding source (e.g., Title IV-E)

• Validate Payment: Verify the receipts received for a one-time payment; Approve the payment for one-time services delivered (Note: This step applies to payments that do not generate invoices)

• Generate Invoice for One-Time Payments: Produce an invoice reflecting amount due in a specific timeframe for one-time payments (e.g., training incentives [Specific to payments in EL)

• Generate Invoice for Ongoing Payments: Produce an invoice reflecting amount due in a specific timeframe for ongoing services (e.g., placement, childcare)

Step 3. Payment Processing

• Issue Payment: Pay the service provider (e.g., ACH/Direct Deposit, Check, EBT

Card, P-card issuance, SSPS)

• Manage Accounts Payable: Manage approvals (of garnishments to AFRS, tax reporting database (TRDB) to AFRS); Process payment corrections

• Manage Reports: Create and publish reports related to providers, services and payments at the individual, program and department level

• Conduct Audits: Perform audits of financial transactions; Perform reconciliations (e.g., checks not cashed, reconciliation of p-card statements). Many operational systems may be consulted in financial audits and not all have been listed in the future state diagrams.

Reporting

DEPS Functional Requirements Functional Requirements Area Summary Description

Purchase Order (Services or Good Authorization)

Describes functional requirements that would purchase order activities related to the following use cases: Purchase Order information ingestion and classification; Invoice production and tracking;

Invoice editing and scheduling; Invoice assignment and categorization; Special Handling, Alerts and notifications; Invoice processing and payment calculation; Budget and encumbrance management; P-card management; Back-end functionality; Invoice validation;

Accounts Payable Management

Describes functional requirements that would support accounts payable management related to the following use cases: Reviewing and modifying payment coding; Annotation and regulatory compliance; Invoice entry and transaction management; Accounting adjustments and credit memos; Accounts payable tracking and monitoring; Accruals and adjustments; Payment distributions; Overpayment collections; Special payment cases; P-card administration; Approval

Functional Requirements Area Summary Description workflow; Tax calculation; Misc.; Interfacing with external systems

Payment Issuance Activities Describes functional requirements that would support payment issuance activities related to the following use cases: Account and fund management; Interfacing with external systems;

Payment approval; Payment controls; Payment disbursement management; Payment Tracking and Monitoring

Process Garnishments Describes functional requirements to process garnishments related to the following use cases:

Ingesting garnishment documents; Structuring ingested data; Aligning garnished entities with payment recipients; Calculation of garnishment amounts; Payment routing

Audit Activities for Underpayment and Overpayment

Describes functional requirements to support audit activities for underpayment and overpayment related to the following use cases: Triggering of under/over payment reconciliation; Categorization and validation of underpayments or overpayments;

Posting of accounting entries; Status tracking, reporting and provider management

Audit Activities for Aging Claims and Checks (Warrant)

Describes functional requirements to support audit activities for aging claims and checks (warrants) related to the following use cases:

Audit, categorize and report aging status of uncashed checks; Issue cancellation request to OneWA Workday and assign General Ledger 5194;

Receive and resolve vendor request for check reissuance

Generate General Reports See Non-Functional Requirements – Data and Reporting Tax Reporting See Non-Functional Requirements – Data and Reporting Payment Recipient Management Activities

Describes functional requirements to support payment recipient management activities related to the following use cases: Register a new payment

Functional Requirements Area Summary Description recipient on the portal; View or update profile information; Send, receive and display notifications and information in Portal; Provide and receive information to support payment authorization; validation of underpayments or overpayments; Posting of accounting entries;

Status tracking, reporting and provider management

Audit Activities for Aging Claims and Checks (Warrant)

Describes functional requirements to support audit activities for aging claims and checks (warrants) related to the following use cases:

Audit, categorize and report aging status of uncashed checks; Issue cancellation request to OneWA Workday and assign General Ledger 5194;

Receive and resolve vendor request for check reissuance

Generate General Reports See Non-Functional Requirements – Data and Reporting

Tax Reporting See Non-Functional Requirements – Data and Reporting

Payment Recipient Management Activities

Describes functional requirements to support payment recipient management activities related to the following use cases: Register a new payment recipient on the portal; View or update profile information; Send, receive and display notifications and information in Portal; Provide and receive information to support payment authorization;

Implementation and Performance

Includes two broad sections and sub-sections:

Implementation Requirements – Project

Management, Requirements Validation, Solutions Design & Development, Data Migration, Testing, User Training, SaaS Solution Provisioning, Cutover/Decommission, Maintenance & Operations, Knowledge Transfer, and a Deliverable List.

Performance Requirements – Incident & Defect Priority, and Service Levels.

System Context

Current State

Figure 1: System Architecture Overview

Interface List Please refer to DCYF Enterprise Payment System Project Scope sheet in the Resource Library.

Planning Phase

The Planning Phase of the DEPS Architecture focuses on preparing the technical and architectural groundwork to support the project’s implementation. This phase ensures that architectural design, dependencies, and integration strategies are thoroughly defined to guide subsequent phases effectively. Key activities include:

1. Architectural Scope Definition:

• Define the boundaries of the architectural scope, identifying systems, components, and interfaces within DEPS.

• Establish alignment with overarching business goals and functional requirements.

2. Current State Architectural Analysis:

• Evaluate the existing technical landscape, including legacy systems and interfaces.

• Identify technical challenges, dependencies, and constraints impacting the target architecture.

3. Target Architecture Alignment:

• Finalize a high-level target state architecture, adhering to principles like modularity, scalability, and cloud-first deployment.

• Confirm architectural alignment with functional and non-functional requirements.

4. Interface and Integration Planning:

• Map all inbound and outbound interfaces, ensuring compatibility and scalability.

• Define initial integration standards, such as API protocols and data exchange formats.

5. Standards and Compliance Check:

• Ensure architectural components meet state and federal compliance standards, including security and privacy mandates (e.g., NIST 800-53, FedRAMP).

• Validate alignment with technical standards like cloud platform preferences and identity management protocols.

6. Risk and Feasibility Assessment:

• Identify architectural risks, such as system dependencies or integration challenges.

• Conduct feasibility analysis for key components, particularly where technology transitions are involved.

7. Architecture Governance Setup:

• Establish governance mechanisms to oversee architectural decisions and changes.

• Define escalation paths for resolving conflicts related to architectural trade-offs.

Future State

Architecture Design Principles DCYF, through collaboration with its partners at WaTech and OCIO, has established the following architectural design principles that guide its approach to DEPS Enterprise Payment Solution architecture and solution design:

Solution Acquisition — Solutions deployed as part of the target DEPS will be acquired from a variety of sources using a combination of contractual arrangements including packages and modules rented as a service, purchased on license, and developed exclusively for DCYF by vendor or state teams. DCYF will seek to achieve best value with each acquisition choice and where possible give preference to rent over purchase over build (custom developed) approaches.

“Cloud-first” Deployment — Solutions deployed as part of the target DEPS will follow the Washington State CIO’s recommended direction to, “think cloud first,” such that, public, private and hybrid cloud solutions are considered before traditional IT platforms.

Cloud Migration — DEPS will prioritize migration of all environments, including Production, to a hybrid and native cloud architecture over time to leverage the available on-demand capacity, scale, flexibility, efficiencies, and cost advantages.

Modular, Composable Business Architecture and Solutions — DEPS will move the enterprise solution architecture toward discrete scalable, reusable modules that make rigorous use of well-defined modular interfaces, support separation of business rules from core programming, and use industry standards for interfaces and can best leverage existing shared enterprise capabilities.

Low Maintenance and Configurability — DEPS architecture will enable and emphasize ease of maintenance, configurability and flexibility to respond to ongoing changes by adhering to principles of modularity, loose coupling, abstraction, low-code development and reusability.

Architectural Resilience — The target DEPS architecture will be able to evolve with changes in the information technology industry best practices and standards and ensure that the solution will not encounter any architectural dead ends.

Integrate Effectively with Existing DCYF Solutions and Systems — The target DEPS architecture will be able to easily take advantage of existing DCYF information technology investments and allow for integration with existing solutions.

Optimal User Experience — The target DEPS architecture will be able to create intuitive, user-friendly UI/UX design using best practices from across industries and allow for future innovations.

System Modernization and Orderly Replacement — Legacy DCYF systems will be replaced by functionality migrated to or developed on the DCYF Integrated Enterprise Platform. DCYF will do this by identifying the high priority business capabilities and features that need to be modernized and enhanced to better serve Washingtonians using modern, cloud-based technologies that can be cost-effectively supported.

Do No Harm — Replacement of high-risk business capabilities and legacy technologies will NOT reduce the level of current automation /operational efficiencies or have a negative impact on current business performance or outcomes.

Continuous Enhancements and Integration — DEPS will adopt a DevOps culture with a focus on implementing and maturing Continuous Integration / Continuous Deployment and fully automated testing practices in support of incremental solution development and deployment.

Vendor Dependency and Lock-in — DEPS architecture and sourcing approach will seek to reduce the state’s dependence on any single technology or service provider and will maximize portability and minimize vendor or technology lock-in and enable the use of state employed and separately contracted staff in M&O activities.

Responsive to Change — DEPS will adopt effective product management practices and disciplines that leverage scaled agile principles to ensure frequent and incremental deployment of the most valuable business capabilities into the production environment.

Representative Governance — The DEPS governance model will ensure proper and effective representation by business and technical leaders from across all DCYF programs that are affected by changes to the business and technical capabilities that make up the DCYF Integrated Platform.

Enterprise-Level Prioritization — The DCYF Integrated Enterprise Platform’s business and technical capabilities and requirements will be prioritized at the DCYF enterprise-level with thorough research and evaluation of the intended benefits and impact on Washingtonians.

Secure and Manageable — The target architecture for the DEPS will be continuously protected against the common internet threats, resilient through disasters and subsequently recoverable, and will be manageable within the existing operational and financial constraints.

Technical Standards and Preferences DCYF, through collaboration with its partners at WaTech and OCIO, has established the following mandatory technical standards and preferences for its DEPS solution:

Security The DEPS architecture prioritizes robust security measures to protect sensitive data, ensure compliance with regulatory standards, and safeguard system integrity. Security requirements focus on identity and access management, data protection (at rest and in transit), and alignment with state and federal policies, including NIST 800-53 and FedRAMP Moderate. These standards ensure a secure, scalable, and resilient system architecture.

• Identity and Access Management: Okta, WATECH SAW (Secure Access WA) MS Entra ID (Azure Active Directory), (Mandatory)

• Application Platform Technologies

• Industry Cloud Platforms (e.g., Azure Power Platform, Salesforce Lightning Platform, etc.) (Preference)

• Multi-Experience Development Platform (Portal Technology)

• SharePoint for Intranet (Preference)

Summary of Functional and Non-Functional Requirements DCYF engaged its external and internal partners, alongside enterprise technical and business SMEs, to define and develop a comprehensive set of functional and non-functional requirements for the proposed DEPS. The requirements are not intended to specifically prescribe the final design of the future state DEPS solution, but rather, provide procurement-level criteria to assist vendors in understanding the needs of the future state system. They include:

• Functional Requirements: Describes the functions that the proposed solution must do to support DEPS business capabilities.

• Non-Functional Requirements: Describes the solution requirements that go beyond those that are directly related to business functionality and are needed to inform choices and decisions about the use and sharing of data, usability, performance, legislation and regulatory compliance, security and privacy, and technology standards compliance.

The following sections provide a high-level summary of the functional and non-functional requirements DCYF developed for the proposed solution.

Future DEPS Functional Requirements Summary The functional requirements are grouped under eight different identified use-cases, and a general category.

Functional Requirements Area Summary Description

General Describes functional requirements that encompasses general solution capabilities that solution may deliver across the payment lifecycle and associated business processes.

Purchase Order Captures functional requirements involving the production of invoices, payment calculations, 3-way validation, alerts and notifications.

Accounts Payable Management

Describes the functional requirements for invoice entry, transaction managements, accounting adjustments, credit memos, p-card administration, and overall AP management.

Payment Issuance Activities Describes the functional requirements associated with payment approval and distribution.

Process Garnishments Describes the functional requirements associated with processing, calculating and routing garnishments.

Audit activities for underpayments and overpayments

Describes the functional requirements associated with tracking, posting, and reconciling under and over payments.

Architectural Refinements and Considerations This section outlines key architectural considerations and refinements required to align the DEPS architecture with its modular, scalable, and secure objectives. This includes ensuring seamless authentication, standardization, scalability, and data security while addressing evolving organizational needs and technical dependencies. These considerations guide the architecture's adaptability and resilience throughout the project lifecycle.

Authentication (Roles/personas)

1. SAW replacement Okta is rolling out in 2025

2. DCYF will need to ensure the project schedule and activities account for SAW activities and that the impacts and timing of these technology and organizational changes are properly managed

3. Authorization (permission levels and audit)

4. NFRs and SLAs

5. Data Standardization (same code/description across systems and interfaces)

6. Scalability (cloud)

7. Data Security (at rest and in-transit)

8. System Observability (usage and exception metrics)

9. Security plan

10. Migration plan o Number of years of transaction data o Number of years of reference data

11. Deployment Plan

DEPS Non-Functional Requirements The following are some of the key DEPS non-functional requirements that need to be considered in development of the solution:

User Experience Requirements Provide a suitable user interface based on device type (i.e., desktop, tablet, smart phone, IVR, etc.) that shall be simple, consistent, and aligned with business process throughout all areas and functions of the System.

• Minimize the number of mouse clicks / user interactions to complete any task, aligned with business process.

• Use a streamlined Graphical User Interface (GUI) across all devices and experiences to help the user navigate to the next logical step in the workflow, or freely navigate to other parts of the System functionality, and then allow the user to return to complete the in-process task aligned with business process.

• Use the users' language, with words, phrases and concepts familiar to the user, rather than System-oriented terms consistent with business process.

• Accommodate diverse populations of users including those with disabilities and limited English proficiency as defined in section 504 of the Rehabilitation Act of 1973.

Audit & Compliance Requirements The Audit & Compliance Requirements section ensures the DEPS architecture supports robust tracking, reporting, and adherence to regulatory standards. This includes maintaining detailed audit trails, enabling secure data access, and ensuring compliance with state and federal mandates such as NIST 800-53. These measures are critical for accountability, transparency, and operational integrity.

1. Maintain a record (e.g., audit trail) of all additions, changes and deletions made to its data in a database management system. In addition, for investigative purposes, the System will provide a log of query or view access to certain type of records and/or screens. The System will provide the ability to search or export this to a report, by user ID, user role, or client ID. This must include, but is not limited to:

• The user ID of the person who made the change

• The date and time of the change

• The physical, software/hardware and network location (IP address) of the person while making the change

• The information that was changed

• The outcome of the event, where applicable (e.g., client name successfully changed)

2. Allow an authorized administrator to set the inclusion or exclusion of auditable events based on organizational policy and operating requirements/limits. The System will log actions by authorized administrators to change these auditable events parameters and provide reports related to such actions.

3. Support logging to a common audit engine managed by a database management system.

4. Detect security-relevant events (as defined in NIST 800-53 moderate baseline, rev 5) that it mediates and generates audit records in a database management system. At minimum, the events shall include, but not be limited to:

a. Start/stop

b. User login/logout

c. Session timeout

d. Account lockout

e. Client record created/viewed/updated/deleted

f. Scheduling

g. Query

h. Order

i. Node-authentication failure

j. Signature created/validated

k. Personally Identifiable Information (PII) export

l. Personally Identifiable Information (PII) import

m. Security administration events

n. Backup and restore

o. Audit Event Types

5. Provide authorized administrators with the ability to read all audit information from the audit records in the following two (2) ways: provide the audit records in a manner suitable for the user to interpret the information. The System will provide the capability to generate reports based on ranges of System date and time that audit records were collected.

6. Export logs into text or spreadsheet format in such a manner as to allow correlation based on time (e.g. Coordinated Universal Time [UTC] synchronization)."

7. Support session replication and seamless failover using high-availability architectural options, including native cloud deployment best practices.

8. Designed such that the System Administration staffing requirements and workload shall be minimally impacted with expanded System usage.

9. Audit trail tracks the data before and after it was changed, and which screens were accessed and used.

Performance and Availability Requirements The Performance and Availability Requirements section focuses on ensuring that the DEPS architecture delivers reliable, scalable, and high-performing solutions. This includes meeting service-level agreements (SLAs), supporting peak operational demands, and enabling rapid recovery from disruptions. These requirements ensure the system remains resilient and responsive to business needs.

1. Built so that there are no component or overall solution limits on its scalability.

2. Leverage virtualization and native cloud capabilities to expedite disaster recovery.

For on-premises components of the solution, virtualization should be used to quickly reconfigure system platforms without having to acquire additional hardware.

3. Provide the ability to recover from data loss due to end user errors and any application errors.

4. Provide direct interfacing with other systems using Application Programming Interfaces (API) and data exchange standards as developed and agreed with DCYF including selected industry standards.

5. Support Application to Application (A2A) synchronous and asynchronous messaging using web services. The messaging capabilities shall be able to support a wide variety of A2A patterns.

6. Interface infrastructure shall continue to operate despite failure or unavailability of individual technology components such as a server platform or network connection.

7. Interfaces shall be scalable to accommodate peak interface usage and changes in scale including changes in user population, transaction volume, throughput and geographical distribution. The System will be capable of making any changes to the interface data elements/layouts easily, and to evaluate those changes.

8. Perform source to destination file integrity checks for exchange of data and alert appropriate parties of issues.

9. Designed for ease of maintenance and readily allow future functional enhancements. This shall be accomplished through use of modern design principles for SOA, applying principles of modularity, interface abstraction, and loose coupling.

10. Manage an average of 150,000 service authorizations and payments monthly and allow for increases without affecting the performance of business operations.

11. Oversee 3000 internal (state employees) users, 15000 external Provider Portal users, and 5000 concurrent users.

12. Capacity to handle 2TB of data at start and is expected to grow by 22GB per month.

13. Adequately flexible to keep up with ever changing technology and regulatory changes. This shall be accomplished by maximizing modularity and loose coupling.

14. Follow all State and federal laws, regulations, guidance, and directives to which the agency is subject.

Interoperability and Integration Requirements The Interoperability and Integration Requirements section ensures the DEPS architecture facilitates seamless communication between systems. This includes supporting standardized data exchange, real-time integrations, and compatibility with external applications, enabling efficient and scalable operations.

• Data look-up and retrieval

• Data look-up with services provided by other applications

• Simple bulk data transfer to/from other Systems

• Business application logic and processes that can also be integrated with, and triggered by, external applications using APIs

Security and Access Controls Requirements The Security and Access Controls Requirements section ensures that the DEPS architecture adheres to stringent standards for safeguarding sensitive data and systems.

This includes implementing robust authentication, authorization, and data protection mechanisms while complying with state and federal security regulations, such as NIST 800-53 and FedRAMP Moderate.

1. Laws, regulations, guidelines, and directives to be published in the future.

2. Safeguard all information, records, data, and data elements in accordance with all relevant State and federal privacy, confidentiality, and security requirements, such as but not limited to:

o Section 543 of the Public Health Service Act, 42 U.S.C. § 290dd-2 and the Confidentiality of Substance Use Disorder Patient Records regulations at 42 C.F.R. Part 2.

o National Institute of Standards and Technology (NIST) 800-53 controls related to the confidentiality, integrity, availability, and privacy of the system.

3. During all phases of the contract, the System shall follow all Washington State OCIO security policies and procedures as currently defined at:

https://ocio.wa.gov/policies/Security?combine=security and as defined in the future.

4. Maintain compliance with the current and all future versions of the NIST SP 800-53 for all services provided under this contract at all times.

5. Use FedRAMP Moderate certified cloud services for all cloud hosting provided under this contract or provide annual independent audit results verifying Vendor’s hosting environments meet Federal Information Security Modernization Act (FISMA) Moderate and NIST SP 800-53.

6. Address the following in the BCM program plan:

o Crisis Management o Business Continuity o Disaster Recovery o Supply chain/third party risk and contingency management

7. Describe the organizational structure for the BCM program office.

8. Show the formal framework (i.e., ISO22301, NFPA 1600, Disaster Recovery Institute, Business Continuity Institute, Federal and Financial Institutions Examination Council (FFIEC), etc.) that it will follow.

9. If certified, the vendor will provide certification number and name of certification body for its BCM/DR related services.

10. If not certified, the vendor will define how often is its BCM program assessed/audited by a third party.

11. Describe the performance management metrics that are used to assess the effectiveness of the BCM program.

12. Define the makeup of its BCM program executive steering committee (e.g., business leaders only, technology leaders only, or both) and provide the roles that are on the steering committee(s).

Business Continuity and Disaster Recovery Requirements The Business Continuity and Disaster Recovery (BCDR) Requirements section ensures the DEPS architecture is prepared for unforeseen events. This includes strategies for system resilience, rapid recovery, and minimal disruption to critical operations, safeguarding organizational continuity.

Solution Management and Monitoring Requirements The Solution Management and Monitoring Requirements section outlines the tools and processes necessary to maintain system health and performance. This includes real-time monitoring, proactive issue resolution, and robust support mechanisms to ensure consistent operational reliability.

1. Offer data archiving capabilities based on Federal and State mandates for the Program(s) being served.

2. Move all historical, expired and/or unnecessary data to offline storage according to a set of business rules and schedule to be defined by the State as a part of the ongoing system operational decision making.

3. Maintain an archival process so that accumulated historical records and log files do not consume large amounts of storage space.

4. Provide an auto archive/purge of the log files to prevent uncontrolled growth of the log and historical records storage using administrator-set parameters as applicable and allowable in alignment with State record retention requirements.

5. Offer modern version control capabilities to ensure the integrity of all development branches, configuration changes, etc.

Notional Target State The Notional Target State section provides a conceptual overview of the future DEPS architecture. It defines key components, such as middleware, transactional systems, and portals, and illustrates how these elements will work together to achieve the desired business outcomes.

Web Tier:

• DEPS Portal

• State DEPS and Employee Portal

• Provider Portal

• Partner Portal

Middleware and Core Service:

• Identity and Access Management

• API Lifecycle management and API Gateway

• Low Code & Business Process Orchestration Engine

• Enterprise Content Management and Document Processing

• Business Rules Engine

• Master Data Management

• Hybrid Integration Platform

• Digital Integration Hub

Transactional Systems:

• CCWIS

• BARCODE

• DEPS + New Modules

• Workday (OneWA)

• Legacy Apps

• Others Core Support Systems

• External IT Services and Operations

Data and Information Infrastructure Services

• Reporting

• Business Intelligence (BI)

• Data Integration and Shared Analytics

• Data Lake or Data Lakehouse

• Enterprise Data Warehouse (EDW)

Design and PoC The detailed designs will be documented in conjunction with the team and the selected vendor.

Implementation Phase

Environments

• Non-production o DEV o SIT

• Production-like o UAT o PERFORMANCE o PROD o DR

Migration Plan The data from existing systems will be migrated to the target platform at go-live. Migration plan is to be determined in partnership with the Vendor.

Test Strategy To be determined in conjunction with the Test Lead.

Go-Live Readiness Go-live runbooks will be produced in association with the vendor.

Maintenance and Operations Transition documents from implementation team will be provided for the M&O team to take over the operations of the system. List of operations and deliverables identified in the Request for Proposal (RFP) will be developed during the implementation phase.

Deployment and Support Deployment and support for M&O activities will be identified in the RFP and through vendor and DCYF operations team collaboration.

Project Timeline

Interface List

Notional Target State