Request for Information (RFI) For: Made in America Architecture Review Issued By: GSA Federal Acquisition Service Technology Transformation Service Office of Regulatory and Oversight Systems 1800 F Street, NW Washington, DC 20405 Background The General Services Administration (GSA) is dedicated to procuring goods and services on behalf of the US Federal Government. As an integral part of GSA, the Federal Acquisition Service (FAS) helps agencies procure innovative solutions and services in a wide range of areas including technology. Within FAS, the Technology Transformation Services (TTS), Office of Regulatory and Oversight Systems (OROS) organization applies modern methodologies and technologies to improve the public's experience with Government by helping agencies make their services more accessible, efficient, and effective, and by itself providing services that exemplify these values. TTS-OROS builds, provides, and shares technology applications, platforms, processes, personnel, and software solutions to Federal Agencies in an effort to help them better serve the public. The objective for this request for information is to support GSA and the Office of Management and Budget's (OMB) Made in America Office (MiAO) in meeting the requirements under Executive Order 14005: Ensuring the Future Is Made in All of America by All of America's Workers and related provisions outlined within H.R.3684 - Infrastructure Investment and Jobs Act (IIJA). This renewed emphasis on Made in America laws is a key facet in a broader economic strategy to increase U.S. productivity and global competitiveness, as well as the resiliency of our manufacturing base to market volatility and manipulation. Recently enacted legislation requires federal agencies to seek waivers or exemptions from OMB when buying other than American made goods, materials and products as well as those issued for infrastructure projects via federal financial assistance grants to state, local and tribal governments. Agencies are also required to post these detailed waivers for public transparency and comments on the MadeinAmerica.gov website. The Made in America program is a joint GSA and OMB-MiAO initiative designed to promote transparency in federal procurement and federal financial assistance by enabling manufacturers and other interested parties to easily identify opportunities by reviewing waivers to Made in America laws. GSA supports the technology behind the MadeinAmerica.gov website, and the OMB Made in America Office approves agency requests for waivers. The Made in America PMO at GSA is seeking information on technical guidance to further develop and maintain the infrastructure and source code supporting the Made in America program. This RFI is meant to achieve the following goals: Gain feedback from industry and any other relevant stakeholders. Better understand how industry would achieve optimal outcomes and efficiency. Identify concerns and potential barriers to implementation. 2.0 Description The Made in America PMO at GSA is responsible for development, operations, and maintenance for the Made in America system. The system currently relies on a COTS stack (Form.io) as the digital forms solution. However, the intent is to migrate off of Form.io while still achieving these objectives: Provide form-related and workflow-related digital services via madeinamerica.gov; Operate, maintain, monitor, and update system deployment and the supporting services underlying the Made in America system in coordination with related teams and/or vendors; Provide ongoing support and continuous development of the Made in America system and infrastructure; Maintain Made in America Authority to Operate (ATO) in collaboration with GSA IT Security to include ongoing software version updates. Support and participate in GSA IT security's continuous monitoring, vulnerability scanning, and remediation processes; Automate operational processes and increase the resilience of the system using best practices of Site Reliability Engineering (SRE); 2.1 Current State MiA at GSA currently operates an in-boundary deployment of form.io on AWS GovCloud as a subsystem, included in the system security plan (SSP) and current ATO. The form.io subsystem exports a form that is embedded in the main app running on cloud.gov, written in Python+Django. The Django app applies the US Web Design System (USWDS) styling. You can see the MiAO site here (login with login.gov to see the waiver forms). There are some challenges with the existing solution, because updating all elements in the stack is difficult and some components are unreliable. The MiA team is also running into software limitations, and it is difficult to expand the system to support post-submission business processes. 2.2 System functional requirements MiA has functional requirements roughly of the following shape. Note: "optionally" means "should be possible, but may not be needed by all forms all the time." Someone (with a login.gov account) fills out a form In-progress work persists between sessions File attachments can be included The form may be multi-step Valid field values can be driven by an API (optionally) a validation runs after each step validation may use data from previous steps Someone (with a login.gov account) submits the form People (or systems) get notified Public elements of the submission can be viewed by the public immediately Public elements of the submission are available via an API for authenticated clients. Private elements of the submission are available via an API for designated authenticated clients. (optionally) People, potentially including the submitter, exchange posts about the submission People (or a system) get notified of each post (optionally) the posts are visible to the public (optionally) Administrators can edit internal fields on the submission, including some not originally in the form (optionally) People, potentially including the submitter, are assigned and prompted for their approval at one or more points Someone (or a system) gets notified Additional elements of the submission are made public There's a (likely internal) summary of how many submissions there have been, and what state they're in. 2.3 Additional Attributes of the Solution Non-functional requirements Support use of login.gov for AuthN (via OpenID or SAML), both for submitters and administrators Styleable with the USWDS Meets 508 / Accessibility standards Desirable attributes Version control friendly Clear path to ATO (at the FISMA Moderate level) Form definitions can be queried in JSON Schema format (for presentation in other contexts) Polyglot customization (usable with multiple languages) Consistent/simple upgrade processes Open source Low vendor lock-in potential Low switching cost Any licensing scales based on usage (not seats) Applicable in similar cases (other programs in the same portfolio have largely similar requirements) 3.0 Requested Information: Industry 3.1 General Company Information Provide a brief summary of your company, to include: Name, mailing address, phone number, and e-mail of Authorized Negotiator(s) and; Business type (large business, small business, etc.) based upon the primary North American Industry Classification System (NAICS) code that your company utilizes for this type of requirement. Identify any Multiple Award Schedule (MAS) contract and related Special Item Numbers (SIN) that your company currently holds. 3.2 Questions for Industry Response What solutions do you recommend regarding the lightweight specification of forms and their validations? Please propose solutions that allow for version controlled specifications for compliance and maintenance reasons. What solutions do you recommend regarding expressing workflow management in a sustainable and maintainable way? What technical architecture or software components would you recommend as suited? Provide a description of potential issues which may hinder delivery and suggested solutions. Are any of these solutions not on your company's MAS contract? 4.0 Responses 4.1 Each response must be single-spaced and written in 12-point Times New Roman font and in the English language. Each response must be in .doc or .docx format with every page of the response separately numbered and must be no more than five (5) 8" by 11" pages in total (excluding applicable diagrams and charts); all pages must be combined and submitted as one attachment. 4.2 Responses to this RFI must be provided electronically to Contracting Officer Justen Proctor (justen.proctor@gsa.gov) and Senior Procurement Analyst Mary Kate Koch (marykate.koch@gsa.gov) no later than the date and time specified in this posting. 5.0 Vendor Meetings Upon receipt of responses, the Government may or may not schedule informal informational sessions with vendors. Meetings may be held in-person or via teleconference. 6.0 Summary THIS IS A REQUEST FOR INFORMATION (RFI) ONLY related to the Made in America program at GSA. This announcement is not a Request for Proposal (RFP) or a Request for Quote (RFQ). The information provided in the RFI is subject to change and is not binding to the Government. GSA has not made a commitment to procure any of the items discussed, and respondents are advised that the U.S. Government will not pay for any information or administrative costs incurred in response to this RFI; all costs associated with responding to this RFI will be solely at the interested party's expense. All submissions become Government property and will not be returned. This RFI does not constitute a solicitation for bids, proposals or quotes and is not to be construed as a commitment by the government to issue a request for proposal/quote or award any contractual instrument as a result of this request. Furthermore, the GSA is not at this time seeking proposals and will not accept unsolicited proposals. Not responding to this RFI does not preclude participation in any future RFP or RFQ, if any is issued. It is the responsibility of potential offerors to monitor the solicitation website(s) such as GSA eBuy, where a potential solicitation of a future requirement may be published. Any document submitted in response to this RFI that contains confidential information must be marked on the outside as containing confidential information. Each page upon which confidential information appears must be marked as containing confidential information. The confidential information must be clearly identifiable to the reader wherever it appears. All other information will not be treated as confidential. All information marked confidential in RFI responses is only for the government's planning use. Confidential information may be reviewed by contractors subject to a non-disclosure agreement (NDA) including, but not limited to, commercial or financial data obtained by the respondent's submitted documents. Otherwise, no information marked confidential included in this document or in conversations connected to it may be disclosed to any other party outside of the government.
