RFI Follow-up _ Questions Answers_final.pdf

RFI 36C10B26Q0286 _ Abacus Visual Playbook Builder Additional Information Requested

RFI Questions and Answers

Questions and Answers received in response to the RFI

Question Answer

1 Response posture. We understand uptime/availability SLAs are not required. For ROM purposes, may we assume a best-effort model with target acknowledgment within 1 business days and restoration within 3 business days of VA reporting an issue?

Confirming the expected posture lets us size standby capacity appropriately.

At this time, the Government is open to suggestions that take reliability and cost savings into account to ensure issues get rectified timely without incurring unnecessary maintenance and sustainment costs for the required services. The Government appreciates any information that can be shared to meet those objectives while we continue to refine our requirements.

2 Code and environment access. Will the sustaining contractor have full access to the application source code with version history, the air-gapped build/release environment, and the existing CI/CD pipeline? This directly determines root-cause and fix effort per incident.

It is an air-gapped environment, so the vendor will not have direct access. They will have to coordinate with VA system owners for access. The vendor is responsible for delivering the source code/artifacts/containers/etc., so they would have a copy of system artifacts. The vendor will build the CI/CD pipeline, and will work in conjunction with VA system owners to rectify any issues to internal VA systems.

3 Continuity of performance. Is sustainment anticipated to be performed by the same contractor that delivers the MVP, or potentially competed separately? This affects ramp-up assumptions in our estimate.

This contract expects the MVP to be delivered in year 1, with this topic of technology sustainment to be option years for the same contract. Whether the prime contractor keeps the same team or enlists new support is up for the prime contractor to determine. At this time, we intend to solicit both the MVP delivery and sustainment years on the same contract. Sustainment will be included as option periods that can be exercised at the Government’s discretion.

4 Incident scope boundary. Can we confirm that each incident is bounded to restoring the affected container(s) to original working state via the existing pipeline, and that any infrastructure change requiring architectural rework (beyond a container-level fix) would be treated as a separate scope item?

The system will go unchanged as far as containers/code are concerned, but these systems need to continue operating (sustainment) with the underlying infrastructure changing through routine upgrades (e.g. HCI, OpenShift, AAP). The goal of the sustainment is to restore all features and the integrity of the system that was met at the end of the MVP delivery, while ensuring that the underlying infrastructure upgrades do not impact a loss of functionality with the original MVP.

5 Licensing model. For the infrastructure licensing line item, should we provide annual cost estimates for VA planning, with VA holding the underlying OpenShift, AAP, HCI, and S3 licenses directly — or does VA anticipate the contractor procuring and passing through those licenses?

The Prime contractor shall deliver a full working solution, which includes all licenses the system depends on (e.g.

HCI, OpenShift, AAP, etc.). VA does not anticipate having more than this one single contractor to both build and sustain the system, which includes any additional COTS annual licenses needed for option years 1-4.

6 STAFFING MODEL: Is the Government expecting a fractional FTE retainer (i.e., a named resource on standby throughout the year), or will the contractor only be engaged on a task-order/as-needed basis when an incident is reported? This distinction has operational implications for access provisioning, clearance requirements, and knowledge continuity that could affect our pricing model and delivery approach.

Contractor will be engaged on an “as-needed basis.”

But essentially we may have no issues, and therefore will place 0 support requests, or we go to perform an infrastructure upgrade, and find the application does not work in some way, and would then need the prime contractor to engage in a technology sustainment fix capacity. VA will do the issue triaging, but we will rely on the vendor for issue root cause analysis.

7 HISTORICAL INCIDENT DATA: The email references an anticipated 0–3 incidents per year.

Can the VA provide historical break/fix incident data from the current environment (e.g., number of incidents over the past 1–3 years, approximate resolution time per incident)? This would allow us to provide a more accurate fixed-price estimate rather than relying solely on the projected range.

There is no current environment, this is a “net new” project, so we have no precedence. However, we currently have an HCI virtual machine infrastructure, and we upgrade that infrastructure 2 to 3 times a year, which is where this projection came from, and will be roughly the cadence we upgrade the Abacus infrastructure.

8 INCIDENT COMPLEXITY/LEVEL OF

EFFORT: Are all anticipated break/fix incidents expected to be comparable in scope and complexity, or does the VA have a sense of the range of effort (e.g., hours or days) a typical incident resolution might require? This will help us structure pricing that reflects realistic surge capacity.

We do not.

This is a “net new” project and therefore cannot speak to the anticipated break/fix incidences.

9 SERVICE LEVEL EXPECTATIONS: Does the VA have any existing or desired SLAs associated with this work (e.g., response time from incident report to acknowledgment, resolution timeframe)? Even informal expectations would help us structure an appropriate offering.

See Question 1.

10 The follow-up notes that during performance the VA will upgrade the underlying infrastructure (OpenShift, AAP, HCI + S3) approximately twice per year, "coordinating directly with Red

The Government does not have any of the licenses for the COTS products detailed and requires the Contractor to provide all licensing as part of their solution for the entire

Hat and HCI+S3 vendors internally," and that vendor coordination with Red Hat or the HCI/S3 vendors is outside the contractor's scope. This suggests the VA may already hold and maintain the OpenShift, AAP, HCI, and S3 licenses directly.

To ensure our ROM is accurate and does not double-count cost, could you confirm how the VA would like these infrastructure licenses represented:

• As Government-furnished licensing already held and renewed by the VA (in which case we would reflect these at no cost to the contract and simply note them as VA-furnished), or

• As contractor-estimated pass-through licensing costs to be carried within our ROM for total cost-of-ownership purposes.

This distinction materially affects the Item 2 figures, so your guidance will let us present the most accurate planning estimate.

period of performance.