RFI_Statement of Objectives_v1.3_final.docx

Draft Statement Of Objectives for: Request for Information (RFI)

Title: Abacus Visual Playbook Builder and Automation Orchestrator

VA-26-00041469

Department of Veterans Affairs Veterans Health Administration (VHA) Veterans Integrated Service Network 23 (VISN 23) Healthcare Technology Management / Biomedical Engineering

1.0 Background

1.1 Operational Problem

VISN 23 Healthcare Technology Management manages clinical workstations and servers across multiple geographically distributed medical facilities. These systems run specialized medical software with vendor-imposed constraints that prohibit agent-based management tools and restrict the remote management protocols available. The environment operates as an air-gapped (dark-site) network with no internet connectivity.

Currently, configuration management and software deployment across these endpoints is performed through manual processes or fragmented scripting, resulting in inconsistent configurations, slow deployment cycles, and limited auditability. The Government requires a system to be titled: “Abacus System” that enables non-technical clinical site administrators to build, share, and execute automation without requiring scripting proficiency, command-line expertise, or deep knowledge of the underlying automation platform.

1.2 Overview

The Abacus System shall leverage commercial platform components, but the integrated solution does not exist as a single commercial product. Respondents should understand that this effort requires contractor-developed software and systems integration, not solely configuration of an existing product.

The Contractor developed software shall include: a browser-based visual playbook builder (the Abacus System’s Web User Interface) with a card-based automation design interface, project/role/card hierarchy management, an editable/stable two-environment workflow model, and a storefront for cross-site content sharing; an Asset Ingress Service enabling browser-based file and folder uploads (which first compress to a single .zip file for storing) to S3-compatible object storage; a custom Ansible collection (abacus.retrieve) that executes on target hosts to download and unarchive/extract .zip assets from presigned S3 URLs during playbook execution; and playbook generation logic that traverses user-created project structures and produces executable Ansible playbooks.

The VA anticipates the following platform components will need to be leveraged (not developed) in order to meet all of VA’s requirements: Red Hat Ansible Automation Platform (AAP) for orchestration and execution; Red Hat OpenShift for container hosting; hyperconverged infrastructure (HCI) for compute and storage; and S3-compatible object storage for asset management.

No vendor currently offers a visual playbook builder that combines card-based Ansible automation design, presigned URL-based asset retrieval, a content storefront with provenance tracking, and dark-site delivery as a unified product. Respondents proposing an existing COTS product must demonstrate how that product satisfies the specific integration requirements outlined in this RFI to include this draft Statement of Objectives.

2.0 Scope

2.1 Objective

The Abacus System is a visual playbook builder and automation orchestrator that allows Government operators to construct, share, and execute Ansible automation through a graphical web interface. The system shall integrate commercial platform components into a unified dark-site solution with the following high-level capabilities. This procurement requires the hardware and hyperconverged infrastructure as part of this contract (see Attachment B for details):

1. Visual Playbook Building: A card-based web interface where users construct automation by selecting modules, configuring parameters, and arranging execution order through drag-and-drop or equivalent interactions, without authoring “Yet Another Markup Language” (YAML) directly.

1. Content Storefront: A centralized repository where published roles, playbooks, and bundled configurations are shared across sites with provenance tracking, version management, maintainer permissions, and site-scoped visibility.

1. Asset Management: Browser-based upload of files and folders (up to 12 GB), compressing assets to .zip before storage, then storing to S3-compatible object storage, with integrity verification and presigned URL-based retrieval and unarchiving/extraction during playbook execution on target hosts.

1. VM Provisioning: User-initiated virtual machine creation on existing Nutanix HCI infrastructure (Visn 23 currently has Nutanix for this VM provisioning workflow (See Attachment B)) through the web interface, with automated onboarding into AAP inventory and optional immediate playbook execution.

1. Multi-Site Operations: Eight (8) physical sites with site-scoped access control, Active Directory integration, and a ninth administrative site (VISN 23) which has cross-site access.

1. Dark-Site Delivery: All components operate in an air-gapped environment with no internet connectivity. Release bundles, container images, vulnerability databases, and Ansible collections must be transferable and installable offline.

2.2 Operational Viewpoint (OV)

The following OV-1 diagram depicts the operational concept of the Abacus System, showing how operators interact with the system, how automation flows from the web interface through AAP to target hosts, and how assets are retrieved directly from S3-compatible storage via presigned URLs during execution.

2.3 Key Architectural Points

1. AAP does not deliver asset payloads. AAP generates presigned URLs and passes them as execution variables. Target hosts shall be able to use the custom abacus.retrieve module (to be developed via this contract) to fetch assets directly from S3-compatible storage via HTTPS. This separates the control path (WinRM) from the data path (HTTPS to S3).

1. All application containers run on Red Hat OpenShift and must be built on Red Hat Universal Base Image (UBI). No non-Red Hat base images are permitted.

1. The Hyperconverged Infrastructure (HCI) platform must be Red Hat OpenShift-certified per the Red Hat Ecosystem Catalog, with demonstrated support for air-gapped OpenShift installation and S3-compatible object storage.

1. Windows hosts are managed via WinRM with certificate-based authentication. No agents may be installed on managed endpoints. OpenSSH cannot be enabled on Windows targets.

2.4 Scale

The Abacus System shall support eight (8) physical sites, up to 50 projects per site (400 total), up to 1,500 managed hosts across all inventories, and at least 10 concurrent users. Individual projects may manage between 1 and 60 hosts. The system must support projects containing 15–35 roles, each with 20–60 actions. The host count of 1,500 is the entire VISN 23 medical device inventory. VA anticipates no more than 100 managed nodes of Red Hat Ansible Automation Platform licenses in the base year. Option years can quote additional license amounts. The onboarding cadence of new medical systems to the Abacus System is dependent on VA. VISN 23 will wait for a project upgrade to initiate the additional work needed to automate a new or existing system. Comment by Minetti, Christopher: Can we just say- VA anticipates no more than 100 managed nodes of Red Hat Ansible Automation Platform licenses in the base year, and an additional ……… in the option periods or something like that. Just to cement the quantities more. Is the onboarding cadence depending on VA or the contractor? Just asking because if it’s the contractor and they say they can do it faster, I assume we wouldn’t want to slow them down. Comment by Biddle, Adam J.: Agreed, stated as such and clarified that it is VA that is the bottleneck here, and we wait for new projects to occur and then plan to convert our inventory via attrition over several years, and therefore do not know the conversion cadence.

3.0 Technology Selection: Red Hat Ansible Automation Platform and Red Hat Openshift The Government has determined that AAP is the only automation platform that satisfies all operational constraints of this environment. Ansible is the only production-proven automation platform that is agentless by design, uses WinRM natively for Windows management with certificate-based authentication, provides comprehensive cross-platform coverage (70+ certified Windows modules), offers an enterprise orchestration platform (AAP) with stable REST API, and supports air-gapped content distribution through Private Automation Hub. Furthermore, this AAP requires Red Hat OpenShift as the certified deployment platform (AAP Operator) to include an OpenShift-certified HCI platform for dark-site deployment. This determination is based on the following six hard constraints, each of which independently eliminates one or more alternative technologies.

3.1 Operational Constraints

3.2 Alternative Technologies Eliminated

4.0. Referenced Documents

The following documents provide detailed requirements and are referenced throughout this RFI. These documents will accompany any subsequent solicitation:

5.0. Contractor Software Development Scope Summary

To assist respondents in understanding the scope and complexity of software development work, the following table summarizes the major functional areas and their approximate requirement counts from the forthcoming Performance Work Statement (PWS), which will be refined as a result of information derived from the RFI. This is not an exhaustive list but represents the primary capability domains.

Total approximate requirement count: ~760 items. The PWS shall be structured to be comprehensive and auditable.

Department of Veterans Affairs Page 1 image1.png