DAAS DBX RFI v2.docx

Request for Information (RFI) For Defense Automatic Addressing System (DAAS) Modernized Message and Transaction Processing.

November 26, 2024

Request for Information (RFI)

For

DAAS Modernized Message and Transaction Processing

This Request for Information (RFI) is issued to support market research in identifying sources capable of providing the system capabilities and requirements detailed below. A response to this RFI is necessary to assist the Government in determining the potential levels of interest, adequate competition, market maturity, and technical capabilities within the Large and Small Business Communities to provide the required capabilities. The Government does not intend to award a contract on the basis of this request or otherwise pay for the information solicited. While the Government intends to use this information for future acquisition planning purposes, it will not release any information about your approach that might in any way compromise your competitive posture or proprietary information. The Government will not use any information provided to level your company’s approach relative to another competitor. Please note that your responses will also be reviewed by our contractor personnel who are providing acquisition support for our digital efforts with appropriate NDAs in place. All information received in response to this RFI that is marked PROPRIETARY will be handled accordingly. The Government will not be liable for or suffer any consequential damages for any proprietary information not properly identified. Proprietary information will be safeguarded in accordance with the applicable regulations. Responses to this RFI will not be returned. Respondents will not be notified of the result of the review. Failure to respond to this RFI does not preclude participation in any future associated RFP/RFQ that may be issued. Information provided in no way binds the DLA to solicit or award a contract.

Background Defense Automatic Addressing System (DAAS) is the DLA Information Operations Business Transaction Service Provider, with the primary mission to receive, edit, validate, route and deliver transactions to the correct destination for the Department of Defense (DoD) Components, Distribution Standard System (DSS) and participating Agencies. DAAS is the interoperable gateway for the DoD Components, Government Activities, Private Sector Entities and Foreign Military Sales (FMS) Countries; providing value-added Network (VAN) services to deliver logistics data to the appropriate destination efficiently, expeditiously, and accurately.

DAAS currently serves 300,000 Business Partners worldwide and processes an average of 9 billion transactions annually. DAAS is a centralized location for logistics data. DAAS is also the authoritative source and custodian of several key DoD databases for supply chain data, including the DoD Activity Address Directory (DoDAAD), Military Assistance Program Address Directory (MAPAD), Project Code Management System (PCMS), Web Fund Code Management System (WFCMS), and Web Supply Discrepancy Reporting System (WebSDR), Logistics Metrics Analysis Reporting System (LMARS). While its core mission has been and will continue to be the processing of logistics transactions, DAAS has expanded its capabilities and mission to include the processing of transactions in additional areas including Supply, Procurement, Financial, Travel, Personnel and Transportation.

DAAS provides transaction-processing services for modern and legacy DoD systems including routing, translation, validation, and aggregation/reporting of logistics data. It allows otherwise disparate systems to connect with each other and exchange transactions and transactional related data, see DGATE and EBUS Profiles below.

By using DAAS, DoD has the ability to efficiently connect otherwise disparate IT systems and technologies, including support for legacy systems and cutting-edge technologies. This means fewer connections are needed to provide system interoperability throughout the DoD, enabling significant cost savings associated with minimal connections and development efforts to support system interoperability.

DAAS offers transaction-processing capabilities for both legacy transaction types and more modernized transaction formats. This includes legacy transactions consisting of Military Standard (MILS) transactions/80 record position formatted, Extended MILS/record position formatted beyond 80 characters supporting Military Standard Requisitioning & Issue Procedures (MILSTRIP), Military Standard Transaction Reporting & Accounting Procedures (MILSTRAP), Military Standard Billing System (MILSBILLS), Military Standard Contract Administration Procedures (MILSCAP) functional business domain. It also includes modernized Electronic Commerce (EC) transactions, which include Defense Logistics Management Standards (DLMS), eXtensible Markup Language (XML), User Defined Formats (UDF), Intermediate Document (IDoc), and Accredited Standards Committee X12 (ASC X12) Electronic Data Interchange (EDI) transactions. Transaction/data processing and exchange is facilitated through the use of modern, secure communication methods including Secure File Transfer Protocol (SFTP), Hyper Text Transfer Protocol Secure (HTTPS), Applicability Statement 2 (AS2), and IBM® Messaging Queue (MQ).

DAAS is currently hosted in an Impact Level (IL)-5 Amazon Web Services GovCloud environment using a multi–Availability Zone (AZ) High Availability (HA) architecture. DAAS is organized into four profiles, each containing mission critical applications and/or infrastructure elements, and is comprised of Commercial-Off-the-Shelf (COTS) and Government-Off-the-Shelf (GOTS) systems. The profiles are defined as follows:

DoD GATEWAY (DGATE) Profile

The DGATE profile represents the entry point for DoD legacy transactions, and EDI transactions into the DAAS infrastructure. DGATE is a key profile for DAAS, which provides a strategic gateway for processing and transmitting the received legacy logistics data to a myriad of activities that operate within the logistics community. The DGATE profile, also, provides for the network and data interoperability within these activities to facilitate the exchange of logistics data. It supports the interoperability of mission support functions, including the capturing of requirements, repository file maintenance, communications exchange, logistics data routing, logistics transaction editing, and distribution. DGATE profile also represents DAAS High Side Gateway (DHSG) capability where High Side customers and their non-MILSTRIP (EDI-X12, UDF, etc.) transactions are processed. The DHSG is a collection of accredited AISs (Automated Information Systems) that receive, process, route, archive, and transmit transaction traffic. Each DHSG AIS is categorized under DGATE profile. DGATE DHSG components provide user management, operational support, web-services, file routing, data set translation & conversion and archiving functionalities. These systems working in conjunction enable DHSG to function as a service organization providing customers continuous access to the DAAS Telecommunications /Automatic Data Processing (ADP) and programming capabilities. Furthermore, DGATE profile supports the interoperability of mission support functions, including the capturing of requirements, repository file maintenance, communications exchange, logistics data routing, and distribution. Current Key Software: Oracle Database Management System (DBMS), Oracle WebLogic, Aurea Sonic Enterprise Service Bus (ESB), IBM® MQ.

DoD ELECTRONIC BUSINESS (EBUS) Profile

The DAAS’ EBUS profile processes standard logistics transactions ((Accredited Standards Committee (ASC) X12, or XML) covered by specific DLMS Implementation Conventions (ICs). As the DoD Components/ Participating Agencies implement the DLMS formats, the DAAS’ transaction-processing workload is continuing to grow for DLMS X12 EDI and XML transaction formats. It is expected that, eventually, as most customers migrate from the legacy DOD MILS fixed record position formatted transactions to the DLMS ASC X12 or other variable-length transactions, such as XML, the modernized X12/XML variable length transaction formats will eventually predominate. The DAAS architecture will ensure that all standard transaction formats, as authorized within the DLMS, are accommodated in the DAAS processing.

Current Key Software Components: GEX, Oracle, IBM® Transformation Extender, Ab Initio, IBM® MQ.

Figure 1: Individual programs within each DAAS Profile

The following diagram depicts the technical landscape Non-Secure Internet Protocol Network (NIPR) for the DAAS (DHSG is not included):

Figure 2: Technical Landscape

DAAS has over 600 connection agreements that cover thousands of connections for system-to-system interfaces. The attached Operational View (OV)-1 illustrates the thousands of data exchanges that DAAS handles with systems both internal and external to DLA to support major functional areas such as logistics, financials, transportation, personnel, procurement and travel. The advantage of this hub and spoke architecture is that it gives a system program manager only one interface partner, DAAS, vice having to manage many individual end-to-end interfaces with multiple systems.

Figure 3: DAAS Operational View Point (OV-1)

API GATEWAY PLATFORM Profile: DAAS has recently implemented an enterprise level Application Programming Interface (API) Gateway capability. The DLA API Gateway is a critical component of DLA's modernization efforts, leveraging the MuleSoft Anypoint Platform as its underlying technology. This capability is designed to streamline and standardize the integration of systems and services across the enterprise, providing a centralized platform for securely managing and exposing APIs. By utilizing the MuleSoft Anypoint Platform, the API Gateway ensures efficient and scalable data exchange between internal and external stakeholders. It acts as a unified interface to enable seamless interoperability across diverse systems, supporting the delivery of mission-critical services and real-time transaction processing. This platform aligns with DLA's broader strategy to enhance data sharing, improve system integration, and drive operational efficiencies while maintaining robust security controls. By incorporating the DLA API Gateway powered by MuleSoft, the agency is better equipped to support evolving requirements and facilitate data-driven decision-making across the Department of Defense and its partner organizations.

Amid evolving operational needs and the challenges posed by aging infrastructure and legacy systems, DAAS is undergoing a comprehensive Digital Business Modernization (DBX) modernization initiative. This effort aims to transform and update its systems and processes to enhance reliability, transparency, and user experience across its operations. The modernization strategy includes leveraging cloud-based technologies to improve scalability and resilience, adopting advanced analytics for deeper insights and decision-making, and integrating more intuitive, user-centric interfaces for a better customer experience. Additionally, efforts to streamline and unify disparate translation and Extract, Transform, and Load (ETL) processes under a single solution are underway, aiming to boost operational efficiency and data integrity.

This modernization will not only consolidate DAAS’s core capabilities but also extend its operational resilience and adaptability, ensuring that DAAS continues to fulfill its mission-critical role in the DoD logistics and supply chain management ecosystem with enhanced proficiency.

Objectives The primary purpose of this RFI is to solicit expertise from software vendors and system integrators to support DAAS in streamlining and consolidating capabilities while also modernizing core message and transaction processing with an API-first approach.

This initiative focuses on the modernization and enhancement of DAAS's critical functions, including transaction processing, data translation, business rules enrichment, and Extract, Transform, and Load (ETL) operations. DAAS’s goal is to explore innovative solutions that will streamline these core capabilities, ensuring a cohesive, efficient, and scalable platform. The objectives driving this modernization effort include:

· Implementation of a Message and Transaction Processing Platform: To deploy a modernized platform capable of efficiently managing and processing a high volume of messages and transactions.

· Adoption of Containerization Strategies: To leverage containerization technology for enhancing the system's scalability, portability, and efficiency. This approach will facilitate easier deployment and management of applications across different computing environments, significantly reducing compatibility issues and improving system resilience.

· API-First Approach: To prioritize the development and utilization of Application Programming Interfaces (APIs) in the system architecture. This approach will promote greater interoperability, flexibility, and innovation within DAAS's ecosystem, enabling seamless integration with other systems and services.

· Leveraging Event and Service Orchestration: To modernize and transform the current fragmented architecture of many point-to-point capabilities to an architecture that orchestrates reusable services. This will enable more agile and efficient management of complex workflows and processes, improving system responsiveness and performance.

· Establishment of a Modern Unified ETL Platform: To develop and implement a state-of-the-art, ETL platform that streamlines the extraction, transformation, and loading processes. This platform will ideally support the consolidation of disparate data sources into a unified system, improving data integrity, efficiency, and accessibility.

· ICAM Compliance and Integration with DLA's Modernized ICAM Solution: To ensure full compliance with ICAM standards and integrate seamlessly with DLA's modernized ICAM infrastructure.

· Full Continuity of Operations Plan (COOP)/Disaster Recovery (DR) Capabilities: To establish comprehensive COOP and DR capabilities ensuring system resilience and reliability in the face of disruptions. This includes the development of robust backup, recovery, and failover procedures to guarantee uninterrupted system availability and data integrity during and after any incident.

DAAS Message and Transaction Processing Architecture Current Architecture Overview As the DAAS is defined as a system and as the organization within which that system operates, it is necessary to define the term system in context. “System” refers to the fact that DAAS is a collective group of technologies, platforms, programs, and customers. The integration of this collective to meet the requirements of organizations that are simultaneously participating as both data providers and data customers is the bespoke system. What is key to modernizing this system to meet the objective of this RFI is to consider what technologies and activities can reinforce this integration while building bridges joining silos of activity and tribal knowledge on standardized platforms to drive efficiency, power high-speed intercommunication and empower the massive quantities of data being exchanged.

Technologies The current technologies interconnected within DAAS include commercial applications, legacy (e.g. COBOL, Java, C++) and modern scripted and coded solutions, government designed and owned software, on-premises implementations, and cloud solutions.

Transaction File Types & Communication Protocols DLA DAAS processes standard military logistics transactions in the form of X12 EDI (Electronic Data Interchange) files, including ASC X12 transaction sets, as well as XML data, all adhering to the Defense Logistics Management System (DLMS) Implementation Conventions (ICs). DAAS also currently processes a smaller volume of Defense Logistics Standard System (DLSS) legacy 80 record position transactions in the Military Standard (MILS) record format, and User Defined File (UDF) formats. Additionally, DAAS provides a message traffic ‘pass-through’ service for those customers who have no direct data exchange communications link(s) with each other. A single input message normally has transactions that could be output in several output messages generated by the DAAS sub-systems. Multiple input messages from various customers may contain transactions that are combined into a single DAAS output message.

DAAS accommodates various communication protocols for receiving and sending messages including AS2, HTTPS, MQ, SFTP, SMTP, etc.

Customers DAAS customers are federal, state, and commercial entities which means that not only is the Defense Logistics Agency a customer of DAAS but that every federal organization that DLA interacts with and every organization that exchanges data with the DoD are possible customers. This poses massive opportunity with proper data empowerment and immense risk with data loss, misinterpretation, or bad handling.

Towards a Unified System Architecture DAAS architecture demonstrates the system’s capabilities with current integration supporting the logistical needs of the DoD and varied additional customers but also provides opportunity to maintain scalability and versatility while unifying existing siloed programs with a modern, agile design based on standardized microservices working as a sole platform for data translation and transformation. Embracing a single, efficient and adaptive architecture will equip DAAS to meet future defense logistics demands more effectively. Unified ETL processing for DAAS will hone robust capabilities empowering data to provide unparalleled insight ensuring DAAS continues to play a crucial role in supporting the DoD's logistics needs indefinitely.

Target State Technical Requirements

The following section summarizes the major components of the target technical architecture for DAAS:

1. Cloud Infrastructure

a) Deployment & Operation: The solution must support deployment and operation within a FedRAMP-Approved IL5 cloud environment to ensure compliance with government regulations.

b) Infrastructure Automation: Will utilize Infrastructure as Code (IaC) for automated provisioning, scaling, and management of cloud infrastructure across development, staging, and production environments.

c) Containerization: Will utilize containers where possible for scalability, automation and resilience / continuity.

2. Message and Transaction Processing Capabilities

a) Message and Transaction Processing Support: Solution should have robust support for processing messages and transactions in various formats including (DLSS) MILS, X12, XML, and User Defined Formats (UDF).

b) API Services: The message and transaction APIs will address the following at a minimum: validation, message and transaction ID assignment for tracing, splitting, translation, transformation of payload, routing, bundling of transactions into messages, reject handling, delivery, status logging and message/transaction archiving.

c) Translation: Capable of translating formats (e.g., MILS to X12, X12 to XML, X12 to UDF, etc.) using prebuilt and custom maps.

d) Transformation: Transforming/enriching transactions by extracting data from various data sources (databases, lookup tables) during processing to meet specific routing and business rules and requirements.

e) High Volume Handling: Must be able to process high volumes of transactions, estimated at an average of 1.1 billion/month for all incoming and outgoing transactions, while meeting service level agreements (SLAs).

f) Surge Volumes: Must be able to support autoscaling infrastructure to handle surge volumes of messages without impacting ongoing transaction processing.

g) Archiving and Logging: Support archiving of each processed message and transaction in cloud storage for audit traceability and reprocessing when necessary, and logging of status in relational databases for tracking, issue troubleshooting, customer support, and reporting utilizing a method of relating each message to its component transactions

h) Transaction Tracing Capabilities; End-to-End Traceability: End-to-end traceability for all messages and underlying transactions. This includes the ability to trace the complete journey of a transaction from initiation to completion across all integrated systems and components and executed microservices for the message and transaction. Provide complete visibility of transactions, including timestamps, message content, and any transformations or processing steps, etc. in real time for the message and transaction.

3. API-First Design

a) Service Deployment: The architecture will incorporate an API-first approach, enabling the deployment of services through synchronous or asynchronous APIs for comprehensive message and transaction processing. SFTP, MQ etc. may be used where constraints exist (e.g. requirements, data volume).

4. Event and Process Orchestration

a) Service Coordination: Utilize platforms like MuleSoft Anypoint ESB for routing and orchestrating services, processes and events as necessary. Utilize transaction tracing and state models for efficient processing and status tracking of all messages and transactions.

5. Container Management

a) Orchestration and Scaling: Must support container orchestration, including capabilities for scaling, automated updates, and secure image management.

b) Security Integration: Integrate with container security tools for continuous vulnerability assessment.

6. Continuous Integration and Deployment (CI/CD)

a) DevSecOps: Utilize DLA-specified DevSecOps tools, practices and pipelines for continuous integration, continuous deployment, and secure coding practices within the cloud environment, incorporating both static and dynamic code analysis tools to ensure secure and compliant code deployment.

7. Security and Compliance

a) ICAM: DLA is implementing its modernized ICAM platform following leverage the DoD Identity, Credential, and Access Management (ICAM) framework. The modernized DAAS solution will integrate all aspects of the architecture including ABAC and RBAC requirements as appropriate for access and execution privileges.

b) Internal Controls: Ensure the necessary internal controls needed to safeguard the completeness, accuracy, and integrity of data are developed and implemented in accordance with DoDI 8510.01 "DoD Risk Management Framework" and other relevant Federal and DoD requirements.

8. Scalability and Performance

a) System Scalability: The solution must be scalable to handle high volumes of message and transaction processing without compromising on performance and should adhere to predefined performance SLAs.

9. ETL Requirements

a) Batch ETL: Develop batch ETL capabilities using Commercial Off-The-Shelf (COTS) ETL software for ingesting, transforming, and loading data (including messages and transactions as they undergo processing) into relational databases or cloud storage solution. This is required for audit, retention and reporting requirements.

b) Streaming ETL: Develop streaming ETL capabilities where appropriate using COTS ETL software for ingesting, transforming, and loading data into relational databases for near real-time operational reporting and support requirements.

Response Instructions Section 1 - Cover Letter

· Company name

· Company business size with socioeconomic classification based on North American Industry Classification Code.

· Company points of contact and contact information (name, address, phone number, email address, and fax number). NOTE: If more than one solution is proposed from a team of providers, all company information should be presented (name, size, etc.).

· Date submitted.

Section 2 - Market Research The purpose of this section is to obtain information from software vendors and system integrators that will assist in identifying potential solutions available in the market to satisfy the requirements and objectives; assessing if there is any additional information that industry requires to better understand the requirements and determine a ROM pricing estimate.

1. Message and Transaction Processing

a) Describe your solution's capability to process messages and transactions in various formats such as X12, XML, MILS, and User-Defined Formats (UDF).

b) How does your solution support the translation from one format to other (e.g. MILS to X12/XML, XML/X12 to MILS etc.) based on specific originator and receiver requirements and rules?

c) Explain how your system validates incoming messages and transactions, and how it handles splitting and bundling of these messages and transactions. [Splitting: A single input message normally has transactions that could be output in several messages with unique destinations generated by DAAS. Bundling: Multiple input messages from various customers may contain transactions that are combined into a single DAAS output message.]

d) Detail how your solution enriches transactions during the transformation process to meet routing rules and other requirements Examples include (but not limited to) cleansing of National Stock Numbers (NSN), cleansing of Fund/Project/Priority Codes, lookup of transaction destinations based on business rules and reference lookup tables etc.

e) What is your solution's capacity for processing high volumes of EDI files and transactions per month while adhering to specified SLAs?

f) What are your various support tiers and associated SLAs?

g) How does your solution support archiving of messages and transactions in cloud storage for audit traceability?

h) Can you detail the status logging mechanism of your solution for EDI processing for issue troubleshooting, customer queries response, and reporting?

i) Per requirement 2.6 “2. Message and Transaction Processing Capabilities” above, how does your solution support end-to-end transaction tracing, visibility into the message/transactions, and correlation of transactions (e.g., a message and its associated logistics transaction), ensuring all files and data are linked and can be traced together despite possible asynchronous processing or traversing different processing steps/services.

j) How does your solution support error handling of improperly formatted or otherwise invalid transactions? Describe how the solution queues, notifies, and workflows resolution of processing errors.

k) If Applicable, provide details on adoption approaches for your solution. How are new users trained (Government or vendors) to operate/configure your solution? What aids, tools, methodologies, learning programs, etc. are available to build a community of users of your solution? How would an Integrator and Government bifurcate and share responsibilities when operating your solution.

2. API-first Approach

a) How does your solution support the deployment of services using synchronous or asynchronous APIs (with or without MQ) for processing EDI messages and transactions? Services could include all the actions needed for processing of the EDI messages and transactions - like validation of messages and transactions, splitting of messages into individual transactions, transformation of data elements in transactions per rules, translation into another format (e.g. MILS to X12/XML, XML/X12 to MILS, UDF to X12 etc.), bundling of transactions into outgoing messages, delivery to target destinations.

3. Cloud Environment

a) How does your solution support deployment and operation within a FedRAMP approved IL5 cloud environment?

b) Can you demonstrate how your solution leverages Infrastructure as Code (IaC) to automate the cloud infrastructure management for deployment across development, staging, and production environments?

4. Event Orchestration

a) Describe how your solution builds routing and orchestration capabilities for processing EDI messages and transactions, potentially using platforms like MuleSoft Anypoint ESB, Aurea Messenger etc.

5. Container Orchestration and Management

a) How does your solution utilize Kubernetes and other container orchestration tools for managing containerized workloads, including scaling and secure image management?

6. CI/CD and Automation

a) Describe your solution's use of DevSecOps tools and pipelines for development, building, and deployment processes within a cloud hosted environment.

7. Security and Compliance

a) How does your solution incorporate the ICAM framework for managing access and execution privileges within a cloud environment?

b) Describe your process for utilizing static and dynamic code analysis tools during the development and testing phases, including remediation practices.

8. Scalability and Performance

a) Explain your solution's ability to scale and meet performance SLAs for high-volume EDI processing.

b) Disaster Recovery (DR) and Continuity of Operations (COOP)

c) Describe your EDI processing and ETL routines' support for continuity of operations across different zones or regions in the event of a disaster.

9. Extract-Transform-Load (ETL)

a) How does your solution build batch ETL code using COTS ETL software that can be scheduled to ingest EDI message and transaction data as-is into a database or object storage solution (e.g. AWS S3). EDI formats could include MILS, ANSI X12. XML etc.

b) How does your solution build streaming ETL pipelines using COTS ETL software to ingest processing event status data from logging tables into relational database for near real-time operational reporting.

c) How does your solution build batch ETL code using COTS ETL software that can be scheduled to ingest extract, transform, load operational data from log tables and tools into data marts/data warehouses for querying, reports and dashboards.

10. Challenges and Risks

a) What challenges and risks do you identify in the proposed Message and Transaction Processing implementation and how will you mitigate them?

b) Can you describe your typical implementation model for complex IT systems in the context of federal agency requirements? Include an overview of associated risks, how you mitigate these risks, and key strategies for maintaining system integrity during and after implementation.

11. Experience with DoD and DLA Systems

a) Describe your company’s experience with and understanding of the DAAS environment.

b) Can you provide a detailed overview of your company's experience with the different tools utilized within DoD, DLA, DAAS and/or supply chain operations (e.g. EBS, JDA, SAP/S4 HANA, FedMall, EDI, eProcurement, Web Federal Logistics Information System (WEBFLIS)? Please include the duration of your experience.

12. Security Measures

a) Outline the security measures implemented to protect in flight data and transactions processed via APIs.

b) Provide details on authorization, authentication, and data encryption methods.

13. Best Practices and Methodologies

a) Share best practices for implementing and managing API-driven solutions at scale.

b) Discuss your approach to API lifecycle management, including versioning, monitoring, and maintenance.

c) Explain how you ensure the reliability of your API services.

14. Level of Effort / Licensing Models

a) What are the major labor categories you would leverage, and estimated hours needed to complete the Tasks, meeting the Technical Requirements and completing the stated Objective?

b) If applicable, provide guidance and details on licensing approaches for your proposed solution.

c) Provide details on ROM pricing for your solution to support the government’s. What is your licensing model(s), approach to upgrades and maintenance fees, license difference between on-premises deployments vs other models (e.g. SaaS), how does containerization impact your pricing and licensing models, or other pricing considerations to be considered by the government.

d) Provide recommended contract vehicles for your licenses or services.

15. Additional Recommendations and Considerations

a) Understanding DAAS’s modernization objectives, provide any additional perspectives or recommendations for the government’s consideration to achieve goals.

16. Previous Implementations and Case Studies

a) Provide examples or case studies of previous implementations in similar environments.

b) Highlight the outcomes, benefits, and any challenges overcome during these projects.

c) Include references or contact information for clients willing to discuss their experiences Note: Section 16 “Previous Implementations and Case Studies” will not count towards the page limit.

Demonstration Request As part of our comprehensive evaluation process, DAAS recognizes the value in witnessing firsthand the capabilities and features of proposed solutions. Therefore, DAAS may extend an invitation to selected vendors for a demonstration of their solution, should DAAS deem it necessary to further understand the potential fit and effectiveness of the offering in meeting our requirements.

This demonstration will provide an opportunity for vendors to showcase the unique aspects of their solution and highlight how it can address DAAS specific needs and challenges. It will also allow for a detailed discussion and Q&A session with the DAAS evaluation team, ensuring a thorough understanding of the solution's functionality, integration capabilities, and potential impact on DAAS operations.

Please note that an invitation for a demonstration does not guarantee selection or imply a commitment from DAAS to proceed with procurement. Rather, it is a step within the DAAS due diligence process to ensure DAAS is making the most informed decision. DAAS encourages all responding parties to provide comprehensive and detailed information in their RFI responses to facilitate the DAAS evaluation process and increase the likelihood of being selected for a demonstration. Vendors who are invited for a demonstration will receive detailed instructions, test data and criteria for the demonstration of the solutions, including the desired format, key focus areas, and any specific scenarios or use cases DAAS would like to see addressed.

Format Responses to this RFI must not exceed 25 pages (8.5x11 inches), single-sided with text no smaller than 12-point in MS Word document or Rich Text File format. Text included in graphics, tables, and figures can be no smaller than 9-point. The cover page, cover letter, and table of contents are not included in the total page count. Any material submitted in excess of the 25-page limit and the page limitation exclusions will not be considered. The submissions must be in sufficient detail and clarity to provide the information needed to assess your company’s ability to provide a solution. In addition, identify a representative to support further Government inquiries and requests for clarification of the information provided, if needed.

Questions If a Contractor believes the requirements in these instructions contain error(s), omission(s), or are otherwise unsound, the Contractor shall immediately notify the below point of contact via e-mail, with supporting rationale, as well as the remedies the Contractor is asking to be considered as related to the omission(s) or error(s).

Response Due Date Interested Sources in the DAAS message and transaction processing RFI must completely address all the above target sate technical requirements in its entirety via response as follows. Email your company capabilities in response to this RFI to Nyeshia.mcallister@dla.mil and Kevin.Buckman@dla.mil.

RFI response must be submitted no later than 17 January 2025, 3:00 PM ET. All questions pertaining to this RFI should be submitted NLT 02 January 2025.

Primary Point of Contact:

Nyeshia Mcallister Nyeshia.Mcallister@dla.mil

(215) 737 -3233

Alternate Point of Contact:

Kevin Buckman Kevin.Buckman@dla.mil

(215) 737 -4220

Contracting Office Address:

DLA Contracting Support Office (DCSO-P) Philadelphia, PA 19111 United States image1.png image2.png image3.png image4.png image5.png