Attachment 1 - Draft PWS.docx

Draft PWS - Enterprise Data Pipeline Modernization and Data Consumption Services Draft Performance Work Statement (PWS) Enterprise Data Pipeline Modernization and Data Consumption Services Databricks Pipeline Development, BI Consumption, Self-Service Analytics, Natural-Language Query, AI-Assisted Legacy Modernization, and Limited Platform Port/Test Support

Table of Contents

1. Purpose The purpose of this Performance Work Statement is to obtain contractor support for the design, development, modernization, testing, deployment, and operational support of enterprise data pipelines within the Enterprise Data Platform. The work is primarily focused on Databricks pipeline development, data ingestion, transformation, BI consumption, self-service analytics, natural-language query, AI-assisted legacy modernization, and sustainable production operations. Platform migration activities, including EDP or CSB environment transition work when assigned, are limited to porting, configuration updates, execution testing, validation, and defect remediation unless the Government separately approves redesign or modernization.

The contractor shall support a data pipeline team responsible for acquiring data from legacy and modern source systems, transforming and curating data in Databricks and related AWS services, and publishing trusted data products for consumption by Tableau, Business Objects Enterprise, Power BI, APIs, self-service analytics, natural-language query capabilities, and AI-enabled modernization use cases.

2. Background The Enterprise Data Platform supports mission-critical data integration, analytics, reporting, and application use cases across multiple business verticals and enterprise programs. The current environment includes AWS cloud services, Databricks, relational and NoSQL databases, legacy mainframe data sources, enterprise BI tools, metadata and governance tools, and DevSecOps automation.

The platform must continue to support existing production workloads while modernizing ingestion, transformation, governance, metadata, and consumption patterns. Key business and technical drivers include:

Limited platform migration support for assigned pipelines, consisting of porting, configuration updates, dependency validation, execution testing, and defect remediation as target platform environments change.

Modernization of ingestion from legacy IBM, Unisys OS 2200, COBOL for z/OS, DB2, and related mainframe sources.

Development of Databricks-based ETL and ELT pipelines.

Delivery of curated data products for Tableau, Business Objects Enterprise, and Power BI.

Support for Compliance Hub, Document Matching, TSOA/IOLA migration, Trump Accounts, Clean Energy, and other priority verticals or applications.

Enablement of self-service analytics, governed data discovery, semantic layers, natural-language query, and AI-assisted modernization of legacy programs.

3. Objectives

4. Technical Environment The contractor shall support work across the following technologies, services, and integration patterns, as applicable to approved Government requirements.

4.1 Cloud and Data Platform Services

AWS.

Databricks.

AWS RDS PostgreSQL.

AWS Redshift.

AWS DynamoDB.

AWS Aurora, where directed or under evaluation.

AWS DMS.

AWS DataSync.

Supporting AWS services for storage, networking, monitoring, security, identity, logging, and automation.

4.2 Data Integration and Movement

On-premises Informatica.

EFTU or enterprise file-transfer mechanisms.

Databricks ETL and ELT.

AWS DMS.

AWS DataSync.

Kafka or event-driven data movement, where applicable.

Batch, incremental, CDC, streaming, and file-based ingestion patterns.

4.3 Business Intelligence and Consumption

Business Objects Enterprise.

Tableau.

IRS Power BI.

APIs and application feeds.

Self-service query tools.

Natural-language query capabilities.

AI-enabled analytical and modernization use cases.

4.4 Legacy and Mainframe Sources

IBM mainframe sources.

Unisys OS 2200 sources.

COBOL for z/OS programs.

DB2.

Copybooks.

JCL or equivalent job schedules.

Flat files, extracts, and legacy data movement patterns.

Business rules embedded in legacy programs or transformation logic.

4.5 Governance, Metadata, and DevSecOps

Informatica Enterprise Data Catalog.

Informatica Axon.

Immuta.

Jira.

Confluence.

GitHub.

GitHub Actions or comparable automation tools.

Databricks Asset Bundles.

Enterprise security, logging, monitoring, and configuration-management services.

5. Scope of Work The contractor shall provide enterprise data pipeline modernization and data consumption services. The contractor shall design, develop, test, deploy, and operate Databricks-based ingestion and transformation pipelines that acquire data from legacy and modern source systems, including mainframe, DB2, COBOL, file-based, database, Kafka, Informatica, and AWS-based sources. Platform migration support, including EDP or CSB transition-related work when assigned, is limited to porting existing pipelines, updating configurations and dependencies, executing validation tests, remediating defects, and confirming consumer readiness. The contractor shall transform and curate data into governed, documented, quality-checked data products for Tableau, Business Objects Enterprise, Power BI, APIs, self-service analytics, natural-language query, and AI-enabled modernization use cases. The contractor shall also support metadata, lineage, data quality, access controls, DevSecOps automation, performance optimization, production readiness, operational runbooks, incident response, key-personnel continuity, and knowledge transfer to Government personnel.

The Contractor shall perform the following twelve (12) major task areas. The formal deliverables supporting these task areas are identified in Section 6, Deliverables.

5.1 Task Area (1): Transition In (Ramp-Up Knowledge Transfer) The Transition-In period shall not exceed one (1) month. During this period, the Contractor shall, upon the Contracting Officer's written notice, furnish Transition-In services as required. As the successor contractor, the Contractor shall have sufficient personnel in place throughout the Transition-In period to ensure a smooth transition from the incumbent Contractor. The Contractor shall provide an orderly transition of work responsibilities to minimize any disruption to Government operations. During the Transition-In period, the Contractor shall become familiar with the requirements, systems, processes, and operational environment to ensure full performance of all contract requirements upon completion of the transition. Transition-In services are not required if the successor contractor is the incumbent Contractor.

The Contractor will appoint a knowledge transfer manager to oversee the transfer of knowledge and ensure all areas are accounted for. If desired, this can be the Project Manager or Project Scheduler. Prior to the transfer of knowledge, the Contractor must develop a draft Knowledge Transfer Plan (KTP) and present it to the Government within the first 10 business days after award. The KTP must identify the Contractor resources and roles involved in the transfer process, provide a list of risks and mitigation strategies for the transfer, and contain a detailed resource balanced project schedule developed with Microsoft Project. The project schedule will identify tasks, dependencies, deliverables, and milestones. The project schedule must be at a sufficient level of detail to track progress on a bi-weekly basis (that is, all tasks will be detailed to a level such that no task has duration of more than 10 workdays). The Government will have five business days to review the draft KTP and provide comments to the Contractor. Government and Contractor representatives will then meet to discuss the comments after which the Contractor must incorporate the agreed-upon changes and deliver a final KTP within five working days of the Government’s feedback. The Contractor will meet with the IRS weekly to discuss the progress of the knowledge transfer. The Contractor must show an updated MS Project Schedule and discuss any risks or concerns at this time. The Contractor must also develop a Transition-In Checklist 10 business days after award to provide a vehicle to verify completion of the necessary transition-in activities. Transition-In checklist must ensure fulfillment of all applicable contractor on-boarding requirements within Appendix E. The Transition-In Checklist must be signed by both the Contractor and the Contracting Officer’s Representative (COR) after completion of the task. The Contractor will perform the following activities during the transition-in period:

a) Assign personnel and submit security papers promptly to get the background investigations done quickly and gain access to IRS’s network

b) Request access to tools and documentation

c) Review and understand all the technical and process documentation

d) Review and understand the existing data and product security policies in place

e) The contractor must provide Ramp-Up Staffing Plan and describe how they will bring resources on board in coordination with the ramp-down efforts of the incumbent

f) The contractors must provide Knowledge Transfer Plan/Checklist Ramp-Up Knowledge Transfer is defined as the Contractor acquiring and understanding the necessary documentation, information, and processes related to any work in progress. This task includes meeting with the IRS Subject Matter Experts and incumbent personnel frequently to gather any tacit knowledge related to the core required tasks.

Transition-In must be worked concurrently with Ramp-Up Knowledge Transfer. Successful transition can be defined by its capacity to maintain full continuity of operations, high productivity, and exemplary service quality. During the transition-in period, the incumbent is responsible for performance. The government estimates these tasks will take approximately one to two months to complete after award.

5.2 TASK AREA (2): Program Intake, Backlog Planning, and Platform Migration Port/Test Tasks Platform migration tasks under this PWS are limited to porting and testing assigned pipelines, jobs, configurations, dependencies, and data products when target platform environments change. This includes tasks required for EDP 1.0 to EDP 2.0 or CSB 1.0 to CSB 2.0 environment moves when directed by the Government, but does not create a separate modernization, redesign, or application-rewrite workstream unless separately authorized. The contractor shall:

5.3 TASK AREA (3): Source System Analysis and Data Acquisition The contractor shall:

5.4 TASK AREA (4): Databricks Pipeline Development and Transformation The contractor shall:

5.5 TASK AREA (5): Data Product Design and BI Consumption

The contractor shall:

5.6 TASK AREA (6): Metadata, Governance, Security, and Data Quality The contractor shall:

5.7 TASK AREA (7): Self-Service Analytics and Natural-Language Query Enablement The contractor shall:

5.8 TASK AREA (8): AI-Assisted Legacy Modernization Support

The contractor shall:

5.9 TASK AREA (9): DevSecOps, Automation, and Deployment

The contractor shall:

5.10 TASK AREA (10): Testing, Performance, and Production Readiness The contractor shall:

5.11 TASK AREA (11): Operations, Maintenance, and Production Support The contractor shall:

5.12 TASK AREA (12): Transition-Out (Knowledge Transfer)

The Transition-Out period shall consist of one (1) month. To minimize any decrease in productivity and to prevent possible negative impacts on additional services, the Contractor shall have sufficient personnel on board during the 1-month Transition-Out period. The Contractor shall ensure a smooth transition with the Government during the Transition-Out period, prior to completion of contractual performance. The Contractor shall aid the Government in the development of plans, procedures, and processes for the assumption of all on going work. The Contractor shall provide an orderly transition of work acceptance and accomplishment, such that full control by the Government is achieved by the end of the Transition Out period. The Transition Out CLIN may be exercised at any point during the duration of the contract.

The Contractor will provide a Transition-Out Plan six (6) months before the end of the contract. The Contractor shall be responsible for the transition of all technical activities identified in this PWS. As part of the transition, the Contractor will be responsible for:

a) Inventory and orderly transfer of all Government-Furnished Property (GFP), to include hardware, software, and licenses; Contractor Acquired Government Property; and Government Furnished Information (GFI).

b) Transfer of documentation currently in process.

c) Transfer of all software code in process.

d) Certification that all non-public IRS information has been purged from any Contractor-owned system.

e) Participate in knowledge transfer activities in accordance with the transition plan.

f) Provide personnel to and participate in transition management team.

g) If the Government provides a Transition-Out Plan template, the Contractor must complete it as assigned; otherwise, the Contractor must submit a Transition-Out Plan at the direction of the government

The Transition-Out Plan must:

a) Document the strategic approach.

b) Identify equipment, hardware, software, documents, and other artifacts that are included in the transition.

c) Document milestones and schedules.

d) Document work-in progress.

e) Identify transition risks and risk mitigation.

f) Define roles and responsibilities.

g) Define transition approval authorities and lines of communication.

6. Deliverables All deliverables shall be submitted in Government-approved formats and repositories, including Jira, Confluence, GitHub, Databricks, metadata tools, shared document repositories, or other approved systems. The contractor shall update deliverables as requirements change, defects are identified, or production changes occur.

7. Performance Standards The contractor shall meet the following performance expectations unless otherwise directed by the Government.

8. Coordination Requirements The contractor shall coordinate with Government-designated teams and stakeholders, including but not limited to:

EDP platform team.

EDP pipeline team.

Vertical application teams.

Compliance Hub and Document Matching teams.

TSOA/IOLA stakeholders.

Trump Accounts stakeholders.

Clean Energy stakeholders.

Tax Processing and legacy source-system teams.

BI teams supporting Tableau, Business Objects Enterprise, and Power BI.

API and application integration teams.

Data governance, metadata, privacy, and security teams.

Cloud, network, DevSecOps, and infrastructure teams.

Product owners, data owners, data stewards, and business consumers.

The contractor shall participate in backlog grooming, architecture reviews, design reviews, production-readiness reviews, release planning, defect triage, incident review, and stakeholder demonstrations as directed by the Government.

9. Assumptions and Dependencies

10. Government Responsibilities

11. Contractor Responsibilities

12. Key Personnel, Staffing Continuity, and Substitution Controls

12.1 Key Personnel Positions

The Government may designate key personnel by role, workstream, labor category, or task order. Key personnel should be limited to positions that materially affect successful performance, source-selection risk, and continuity of critical technical knowledge. Unless otherwise specified in the solicitation or task order, the following positions are recommended as key personnel for this requirement:

Data Pipeline Technical Lead.

Senior Databricks Data Engineer or Senior Data Engineers assigned to critical pipeline workstreams.

Legacy Data Modernization / Mainframe Integration Lead.

Data Governance, Metadata, and Data Quality Lead.

DevSecOps / Deployment Automation Lead.

BI and Semantic Layer Lead, when BI consumption or semantic modeling is in scope.

AI / Natural-Language Query Enablement Lead, when AI or self-service analytics work is in scope.

Production Support / Site Reliability Lead, when operations and maintenance support is in scope.

The Contracting Officer may designate additional or fewer key personnel based on the final acquisition strategy, task-order scope, period of performance, and evaluation approach.

12.2 Government Furnished Property (GFP) and Government Furnished Information (GFI) Government furnished property (to include material, equipment, and/or information) shall be provided in the performance of this contract. The IRS will provide the following property:

Government furnished information (including manuals, notes, memos, instruction materials, and other information) shall be provided during the performance of this agreement. The IRS will provide the following information:

12.3 Materiality of Key Personnel

The contractor's proposed key personnel are material to the Government's evaluation, source-selection decision, award decision, and assessment of performance risk. The contractor shall provide the named key personnel identified in the accepted proposal and incorporated into the contract at the level of effort, role, and start date approved by the Contracting Officer.

The contractor shall not treat proposed key personnel as interchangeable labor resources after award. Reassignment to another contract, internal project, business development activity, corporate initiative, or lower-priority task shall not reduce the approved level of effort for this contract unless approved in writing by the Contracting Officer.

12.4 Key Personnel Commitment Letters and Availability Certification The offeror shall submit a signed commitment letter for each proposed key person. Each letter shall be signed no earlier than the date specified in the solicitation and shall state that the individual:

Authorizes the offeror to use the individual's resume and qualifications in the proposal for this requirement.

Is willing and available to perform the proposed role at the proposed level of effort upon award and through the required performance period, subject only to circumstances outside the individual's or contractor's reasonable control.

Understands that the Government may rely on the individual's qualifications, experience, commitment, and availability in evaluating the proposal and making the award decision.

Has disclosed to the offeror any known conflicting commitment that would prevent performance at the proposed level of effort.

The offeror shall certify that it has a reasonable basis to expect that each proposed key person will be available to perform the contract as proposed. The offeror shall promptly notify the Contracting Officer if, before award, any proposed key person becomes unavailable or the offeror no longer has a reasonable basis to expect that the person will perform.

12.5 Restriction on Substitution, Reassignment, and Reduced Level of Effort The contractor shall not remove, replace, substitute, reassign, or reduce the approved level of effort of any key person without prior written approval from the Contracting Officer. No substitution, reassignment, or level-of-effort reduction is effective until approved in writing by the Contracting Officer. Approval by the Contracting Officer's Representative, program office, technical monitor, task lead, or other Government personnel does not constitute approval for purposes of this section.

For the first 180 calendar days after award or start of performance, whichever is later, the contractor shall not propose a voluntary substitution of key personnel except for circumstances outside the contractor's reasonable control or when removal is directed or approved by the Government. Business convenience, internal reassignment, competing contractor priorities, post-award recruiting failure, or use of the individual on another contract shall not be considered sufficient basis for voluntary substitution during this initial period.

12.6 Notice of Actual or Anticipated Unavailability

The contractor shall notify the Contracting Officer and Contracting Officer's Representative within 1 business day after learning that a key person is unavailable, may become unavailable, may be unable to perform at the approved level of effort, or may not start on the approved start date. The notice shall include the reason for actual or anticipated unavailability, affected workstreams, immediate mitigation steps, and the expected date for a formal substitution or backfill package, if required.

For a voluntary substitution or planned reduction in level of effort, the contractor shall submit a complete substitution request package at least 30 calendar days before the proposed change. For emergencies or circumstances outside the contractor's reasonable control, the contractor shall submit the package as soon as practicable and no later than 5 business days after the initial notice, unless the Contracting Officer approves a different schedule.

12.7 Required Substitution Request Package

A key-personnel substitution request shall include, at a minimum:

Name, role, employer, proposed start date, proposed level of effort, and availability of the proposed replacement.

Detailed explanation for the substitution, including supporting documentation when available.

Current resume of the proposed replacement.

Qualification matrix comparing the proposed replacement against the solicitation minimum requirements, the accepted proposal…