Attachment 0003 - FMS-ACES Statement of Objectives (SOO).docx

Foreign Military Sales - Army Case Execution System (FMS-ACES)

Statement of Objectives (SOO) DRAFT

Version 1.0

11 August 2023

Prepared By:

Product Lead, FMS-ACES

Revision History

APPROVALS

Ms. Kelly A. Rutherford Product Lead Foreign Military Sales – Army Case Execution Date System (FMS-ACES)

Ms. Amy J. Young FMS-ACES Functional Lead United States Army Security Assistance Command Date

(USASAC)

Table of Contents

List of Figures

List of Tables

FMS-ACES Objective The U.S. Army is seeking to sunset its current system used for the management of Foreign Military Sales (FMS) cases, Centralized Integrated System - International Logistics (CISIL) system, an antiquated mainframe system built with Common Business Oriented Language (COBOL). As such, CISIL is unable to keep pace with modern technology and directives to include migration to the cloud, cybersecurity defense, auditability, and financial compliance. The use of outdated language and the inability to make significant enhancements to CISIL has also made data visibility and reporting difficult. As a solution, the Case Management Application (CMA) and Army Reports modules were purpose-built to improve and enhance Army FMS business processes and customer interactions. CMA is the Army Security Assistance Enterprise (ASAE) workflow and workload management tool that provides a modern computing environment and a suite of functionality needed to accomplish the Army FMS mission. CMA enables logic and functionality not able to be included in CISIL. Army Reports is an internal business intelligence system developed by the Defense Security Cooperation Agency (DSCA) to replace the prior ad hoc reporting system that was used for reviewing Army FMS data and generating reports. Both CMA and Army reports will be included in the solution.

The DSCA relies on the military departments to conduct data collection, maintain data integrity, and assure interoperability requirements can meet the needs of the FMS enterprise. DSCA, through U.S. Army Security Assistance Command (USASAC) has tasked the Army’s Program Executive Office Enterprise Information Systems (PEO EIS) to award a contract for the FMS-ACES solution. This document describes the objectives that the FMS-ACES program must meet to achieve success.

High-Level Outcomes Table 1 provides the High-Level Outcomes desired for the FMS-ACES end state.

Table 1: FMS-ACES High-Level Outcomes

The intent of the FMS-ACES program is to leverage commercial technology wherever possible, in the form of no-code/low code commercial Software as a Service (SaaS) Cloud Service Providers (CSP), to minimize lifecycle support requirements. While the Army and PEO EIS will be required to monitor and control in areas such as cybersecurity and legal compliance, this approach shifts a large portion of the burden to maintain and upgrade the technology stack to the CSP. The Operational Community (OC) benefits from having a solution that is flexible and adaptable, able to adjust to emerging or changing ASAE requirements which can be prioritized and planned as part of “software never done” Continuous Integration/Continuous Development (CI/CD) efforts. In the pursuit of the most flexible and adaptable system possible that supports the ASAE’s outcomes, the program will consider and pursue opportunities to leverage existing Army infrastructure and/or capabilities. These can include ICAM, the cARMY Infrastructure as a Service (IaaS)//Platform as a Service (PaaS) environment, and Development Security and Operations (DevSecOps) tools such as the Code Resource and Transformation Environment (CReATE) ensuring that the FMS-ACES OC is provided with a holistic best-of-breed solution that is flexible, adaptable to changing needs, and resilient to the effects of time.

Background Stakeholders The execution of FMS and other security cooperation programs fulfills the commitment of the United States Government (USG) to foreign governments and other international organizations to provide defense articles and services to strengthen their defense capabilities, participate in international coalitions, and respond to Humanitarian Assistance (HA) and Foreign Disaster Relief (FDR) efforts.

The USG authorizes the sale, lease, and grant of military equipment, including spare parts, to international customers through government-to-government agreements or internal USG agreements. Sales are tracked by the enterprise as FMS Cases. While multiple organizations across the Federal Government are interested parties in FMS, the primary stakeholders of the ASAE are as follows:

· Department of Defense (DoD): The Secretary of Defense establishes military requirements and implements programs to transfer defense articles and services to eligible foreign countries and international organizations. Within DoD, the principal responsible agencies for Security Cooperation (SC) are DSCA, the Combatant Commands (COCOMs), the Joint Staff, Security Cooperation Organizations (SCOs), and the Military Departments (MILDEPs).

· Defense Security Cooperation Agency (DSCA): Directs, administers, and provides guidance to the DoD Components and DoD representatives to U.S. missions for the execution of DoD SC programs for which DSCA has responsibility.

· Deputy Assistant Secretary of the Army for Defense Exports and Cooperation (DASA DE&C): Leads the ASAE through the United States Army Materiel Command (AMC), the USASAC, Lifecycle Management Commands (LCMC), and Minor Implementing Agencies (IA). The ASAE develops solutions that deliver capabilities to partner nations through government-to-government relationships using the FMS process.

· Subordinate organizations and resources are depicted in the following organization chart:

Figure 1 Operational Community

Within the stakeholder organizations and the ASAE are approximately 1000 users at various locations within the Continental United States (CONUS). These users track and action approximately 88,000 active requisitions within 6,200 cases.

Vision The vision for FMS-ACES is to develop a system that combines the case management process support with a flexible reporting capability while having connectivity to all supporting and supported systems that will enable the Army’s IT Modernization efforts. The future state is represented in Figure 2, the left side depicting bolt on functionality with the streamlined integration and future core capabilities in the middle and right side.

Figure 2 Desired End State of FMS-ACES Concept of Operations FMS-ACES will be a modernized, cloud-native, Army FMS management, tracking, and reporting system which implements a DoD enterprise approach using Title 22 U.S.C data standardization requirements while ensuring compliance with ASAE standards. FMS-ACES will include a RBAC mechanism to define roles and privileges for system use and will achieve system security compliance and overall auditability in accordance with Financial Improvement and Audit Readiness (FIAR) / Federal Information System Control Audit Manual (FISCAM) standards. Significant useability gains will be realized in FMS-ACES when compared to the legacy CISIL system in the form of a modern user interface and user experience (UI/UX) and deeply integrated business and validation rules will allow the system to assist the user with case management activities. Developing a new system removes obsolescence in current reporting, creating a modernized sustainable product successfully integrating Army and DoD systems.

Figure 3 FMS-ACES Operational View (OV) 1

Capability Areas The ASAE requires an FMS case execution management tool to oversee Army FMS activities, manage cases to ensure compliance with Laws, Regulations, Policies and Directives (LRPDs) associated with FMS, fulfill requisitions, report statuses and issues across the DoD SC community, prepare ad hoc reports to congress and DoD, while doing so in a secure and auditable manner. This new system needs to satisfy DoD ICAM and cybersecurity requirements as well as DSCA Case Execution Modernization Initiative (CEMI) standards and principles while providing a holistic and up to date common view across the Army FMS portfolio. Currently, USASAC has no system or combination of legacy systems that provides the required capabilities to meet DoD FMS and cybersecurity requirements. USASAC’s capability needs have been categorized into eight (8) capability areas that encompass Army FMS, Security Cooperation, DSCA CEMI, and DoD security requirements. The capability areas are defined below.

Capability Area – Case Initiation The Case Initiation Capability Area consists of a group of interfaces and data received from the Case Development system of record (DSAMS - Defense Security Assistance Management System) that provide legal and regulatory authorizations.

Create Case Master Records

Track Letter of Offer and Acceptance (LOA), Amendments, and Modifications from proposed to offered status Capability Area – Case Implementation The Case Implementation Capability Area consists of case and line/subline level baseline data, including financial and logistical controls which are used to manage case execution and enables the tracking of cost/schedule/performance.

Initiates the case execution process

Emergency Implementation Capability Area – Logistics The Logistics Execution Capability Area consists of a set of procedures for creating, processing, updating, and tracking Requisitions (aka Customer Orders), maintain current and accurate statuses of shipments, and documenting receipt of requested goods. These procedures provide a single comprehensive logistical status of each customer's order across the domestic supply systems.

Initiating requisitions

Managing requisitions: Supply Status, Shipment Status, Modifications and Cancellations

Managing Special Processes: Cooperative Logistics Supply Support Arrangement (CLSSA) Program, Supply Discrepancy Reports (SDR) etc.

Capability Area – Financial Execution The Financial Execution Capability Area consists of procedures for requesting distribution of funds, managing Interfund (Direct Cite) / Non-Interfund (Centralized) billing, reporting these transactions to financial databases, and managing and reporting performance and fund status to Defense Integrated Financial System (DIFS).

Case/Line Funding

Customer Billing (interfund and non-interfund)

Capability Area – Case Lifecycle The Case Lifecycle Management Capability Area consists of a series of procedures and status reports to manage case execution and measure performance. Major procedures include Case Execution Performance, Case Management Alerts, Case Master Plan, Case Review, and Case Requisition Review.

C1 (major item) Delivery Reporting

Centralized Error Correction Activities Capability Area – Case Closure The Case Closure Capability Area consists of a series of procedures and reports to manage the FMS Case Closure program at case, line/subline, and requisition level. These procedures assign case / line closure responsibilities, prioritize workload based on the overall position of the case, and track closure progress with visibility to all key stakeholders. These procedures allow logistics review, financial reconciliation, and line certification as each line becomes supply service complete (SSC) throughout case execution.

Case/Line Certification

Interim to Final Certification Capability Area – Foundational The Foundational Capability Area consists of common processes that span multiple capability areas.

Establish defined User Roles and Permissions [Create, Read, Update, and Delete Capability]

Upload, transmit, and retain external documentation [PDFs, Word, Excel]

Ability to Print/Create and systemically set automatic alerts to users based on defined logic

Querying and reporting capabilities

Financial and logistics auditability

Web-based, intuitive, and interactive user interface Capability Area – Non-Functional (Technical requirements) The Non-Functional (Technical Requirements) Capability Area consists of the system architecture, design, technology stack, and implementation of United States Department of the Army (DA), DoD, and national Institute of Standards and Technology (NIST) standards that allow a system to operate securely and reliably on the DoD Non-classified Internet Protocol (IP) Router Network (NIPRNet) while meeting audit standards.

Compliance with DA and DoD Identity, Credential, and Access Management (ICAM) standards

Compliance with DA and DoD Zero Trust Architecture (ZTA) standards

Implementation of NIST controls and compliance with DA cybersecurity standards

Implementation of a RBAC system design to allow an approach of restricted privilege and access to protect information

Compliance with Army Cloud Plan objectives and guidelines

Compliance and integration with DSCA CEMI objectives, policies, and guidelines to achieve a federated FMS enterprise

Infrastructure and application architecture design that support performance, availability, and reliability requirements

Compliance with the Army Strategic goals for Data modernization including data visibility interoperability, with modernized data management and governance capabilities supported by independent data repositories which comply with Department of Defense Architecture Framework (DODAF) standards and DOD Information Key Performance Parameters (KPPs) Enterprise Requirements The FMS-ACES draft system requirements (functional and non-functional) are defined in the Requirements Traceability Matrix (RTM) tab of the FMS-ACES Requirements Master List (RML).xlsx (Attachment 004). FMS-ACES requirements fall into one of the eight (8) Capability Areas. Additionally, the FMS-ACES requirements are aligned to a “Category” where applicable to further delineate the area in which the requirement will be implemented. These categories are:

UNCLASSIFIED

UNCLASSIFIED

UNCLASSIFIED

FMS-ACES SOO

V 1.0

· Alerts and Notifications

· Audit

· Alerts and Notifications

· Audit

· Audit readiness & Compliance

· Billing

· Business Process Workflow Automation

· Common Operating Picture (COP)

· Compliance

· Cyber

· Data

· Data Management

· Data Migration

· Data Quality

· Data Retention

· Data Validation

· Defined User Roles

· Disaster Recovery

· Document Management

· Interface

· Interoperability

· LRPDs

· Performance

· Processing

· Query/Report

· Reliability, Availability, and Maintainability

· Remarks

· Review

· Single Data Entry

· System Availability

· User Interface (UI)/User Experience (UX) The RML also includes capability descriptions, Interface information, relevant Laws, Regulations, Policies, and Directives (LRPDs) and Acronyms. In addition, refer to the current operational views to obtain a better understanding of how the operational community achieves their business today.

The RML is a living product, and it is expected that minor changes will continue to be made until prototype award.

Product Roadmap The FMS-ACES roadmap depicts the delivery of capabilities based on case types managed by USASAC. Using a case type decomposition of the workflows and business processes ensures as functionality is introduced in FMS-ACES, the full workstream can be performed in the application and removed from the legacy CISIL environment. This approach reduces risks associated with split operations in multiple systems.

Figure 4 FMS-ACES Strategic Product Roadmap Application architecture, design, development, integration testing, deployments, and maintaining the infrastructure and application will be the responsibility of the solution provider and lead systems integrator. The solution provider will be responsible for developing unit tests for functionality and features as well as conducting integration and security testing for the application in every sprint. Ideally, these tests will be integrated into the CI/CD pipeline and conducted in an automated manner for every build. User acceptance testing will be the responsibility of USASAC. The FMS-ACES product lead and Program Management Office (PMO) team (both federal employees and Systems Engineering and Technical Assistance (SETA) support) will monitor, track, provide oversight on integration efforts, track risks, manage the schedule and tasks to ensure the application meets requirements, is efficiently developed and delivered, and meets the PEO EIS standards.

Current Business Environmental Challenge Each MILDEP has their own FMS systems that support DSCA efforts by managing and tracking FMS cases through their lifecycle. The Army’s principal FMS system is CISIL, developed in the 1970s using COBOL / NATURAL language technologies and remains hosted on a mainframe. Due to the antiquated languages and the inability to make significant enhancements to CISIL, the system is not able to synchronize its data and statuses with the DSCA systems. As a result, DSCA is often challenged to report on Army statuses because it lacks sufficient visibility into case execution data.

As a solution to this challenge the Army uses two modules to support and enhance CISIL data: the CMA and Army Reports. USASAC built CMA as the ASAE workflow and workload management tool supplementing CISIL by providing a modern computing environment and a suite of functionality needed to accomplish the Army FMS mission. The CMA enables logic and functionality not able to be included in CISIL. It also includes case alerts, user workload assignments, historic data capture, performance measurement and Defense Performance Management and Appraisal Program (DPMAP) functionality, document workflow, and form preparation and production. The second module, Army Reports is an internal business intelligence system developed by DSCA to replace the prior ad hoc reporting system Model 204 (M204) which was used for reviewing Army FMS data and generating reports.

Due to CISIL’s antiquated programming languages, architecture, and a lack of available developer and testing resources, only critical mission requirements have been updated since 1996. Additionally, the lack of an RBAC mechanism to define roles and privileges for system use impacts the security of the system and overall auditability, specifically FIAR / FISCAM compliance.

The problem boundaries can be defined functionally, organizationally, and technically. Functionally, the business needs are specific to the subset of security cooperation business processes related to case execution. Organizationally, a wide range of entities need to access and / or manage case execution data, from the Department of State (DoS) for high-level case execution reporting to the MILDEPs / lAs where most case execution data is generated.

The desired end state is a modernized, cloud-native, Army FMS management, tracking, and reporting system that subsumes CISIL, CMA, and Army Reports capabilities, while implementing a DoD enterprise approach and achieve data standardization that efficiently and effectively supports FMS programs and the ASAE at large.

Period and Place of Performance The award of the FMS-ACES solicitation is anticipated on or around Q3 FY2024, following a competitive prototype selection period. The competitive prototype period of performance will be no longer than five (5) months and will seek to develop an initial set of FMS-ACES requirements. Upon completion, one (1) Contractor will be awarded a follow-on prototype agreement to develop and deploy a minimum viable capability release (MVCR) into a production environment. The Government plans to award to the same prototype agreement awardee a production agreement that will continuously enhance the FMS-ACES solution.

The place of performance will be a mixture of virtual (leveraging the Government’s Office 365 and CReATE tools), Contractor facility, and Government facilities as needed, to include operational community facilities around New Cumberland, PA and the program office in Crystal City, VA. Beginning with step 5, all personnel associated with the upward invited offeror(s) must be eligible to obtain a Common Access Card (CaC) to perform the associated step. General information regarding the CaC process can be found at https://www.cac.mil/Common-Access-Card/Getting-Your-CAC. Detailed information will be provided in the upward invite, to include training requirements (e.g. security, cybersecurity, PII/CUI, and antiterrorism training) and documentation requirements (e.g. Acceptable Use Policy, DD Form 2875). If required, the Contractor must provide the capability to host key program activities that require on-site collaboration with Government representatives at no additional cost to the Government.

Travel will be required to perform the duties of the agreement. Government-directed travel may be necessary; however, the number of required trips is unknown and will be based on necessity. Travel will be approved on a not-to-exceed trip basis by the Government AOR prior to departure. Travel to support step 5 activities is included in the amount specified in the Announcement and Instructions document and not reimbursable. Local travel is defined as travel above and beyond the commute to and from the normal worksite. Local travel will not be reimbursable. All travel must be in accordance with the Joint Travel Regulation (JTR) (https://www.travel.dod.mil/) and U.S. General Services Administration (GSA) guidance (https://www.gsa.gov/travel/plan-book/per-diem-rates). Travel estimates will accompany the offeror’s PWS in order for the Government to understand support requirements for the included tasks.

Constraints As directed by the Army, the FMS-ACES modernization solution will be hosted in an Impact Level 4 (IL4) DoD-approved cloud environment and must meet the Federal Risk and Authorization Management Program (FedRAMP) security qualifications. The modernized solution must support Army and non-Army partners and be able to interface with other FMS and partnering systems using real-time exchange methods when possible.

The Defense Logistics Management Standards (DLMS) will be used for transactional and automated information exchange. Translation methodology will be required to data exchange with legacy system that still use the outdate Military Standard Requisitioning and Issue Procedures (MILSTRIP) standard.

Application access will be provided to users via secure methods and access to data will be limited based on roles and responsibilities. Modern software will be used for application development and UI/UX design.

FMS-ACES functionality will be incrementally delivered into production over the duration of the Other Transaction Agreement (OTA). This will require the user community to perform FMS operations in FMS-ACES and the in the Army’s legacy FMS system (CISIL) until full capability is delivered. Due to the brown-out state of the legacy system, changes or modification to the legacy source-code is not permitted (i.e., strangler patterns may not be applicable in this instance). As a result, the solution provider must ensure the capability to conduct split operations without duplicating data in both systems while maintaining accurate reporting for Army FMS activities.

Interoperability FMS-ACES will be required to exchange data with a minimum of twenty-six (26) partner systems to support the eight (8) capability areas. Three (3) of the 26 interfacing systems have been identified as major systems due to the number of system-to-system interactions throughout the lifecycle of a case. These major systems include Defense Automated Addressing System (DAAS), Defense Security Assistance Management System (DSAMS) and General Fund Enterprise Business System (GFEBS). The mapping of the interfaces to the core capabilities can be found in the System View-3 (SV-3): Systems-Systems Matrix architecture document. The KPPs and Key System Attributes (KSAs) are identified in the RTM tab of the FMS-ACES RML.

To meet interoperability and supportability requirements, FMS-ACES will develop an Information Support Plan (ISP). The plan will describe the interface requirements and systems dependencies that will enable testing and verification of the interfaces. It will also identify risks related to infrastructure and provide steps to resolve and mitigate them.

Establishment of a Governance Board consisting of members of USASAC, DSCA and other government members, will ensure FMS-ACES compliance with DoDI 8330.01 (Interoperability of Information Technology) and all criteria to achieve Net-ready certification based on guidance provided in the Chairman of the Joint Chiefs of Staff Instruction (CJCSI) 5123.01.

The FMS-ACES system will be built in compliance with Army Cloud Plan 2022. Application users will access the system through the NIPRNet, or through virtual private network (VPN) via the Defense Information Systems Agency (DISA) Internet Access Point (IAP). As part of this modernization effort, the objective end state for the interfacing systems is 100% conformance to modern application programming interface (API) to allow more efficient, real-time data processing. Some of the interfacing systems lack API capability, for those systems, FMS-ACES will continue to use secure file gateway (SFG) until those systems are able to modernize. In accordance with DoDD 8190.01E, FMS-ACES will use the mandated Defense Logistics Management Standards (DLMS) for transactional and information between all DoD systems.

FMS-ACES data will be owned by the government and data will only be accessible to external systems via API or SFG for legacy systems. Data will be available to registered users via system interfaces and report generation. Users will only have access to information appropriate for their role as assigned by the system owner during account configuration. The Unified Data Reference Architecture (UDRA) will go into effect while FMS-ACES is under initial development. The system will be UDRA compliant and will support CEMI Federated Data Governance concepts and policies.

Relevant Laws, Regulations, Policies and Directives (LRPD) Various LRPD have been established to govern and regulate DoD activities and missions across the defense enterprise. Section 22 of the Arms Export Control Act (22 U.S.C. 2762) authorizes DoD to enter into contracts for resale to foreign countries or international organizations. The Security Assistance Management Manual (DSCA 5105.38-M) provides DoD-wide guidance on the management and implementation of DoD Security Assistance and Security Cooperation programs over which DSCA has responsibility.

LRPD requirements related to the implementation of the Army FMS process are provided in the LRPD tab of the FMS-ACES RML. As this effort progresses, certain regulations and policies may need to be updated or waived to enable opportunity for increased business process efficiencies that may be identified.

Business Process Reengineering (BPR) The current technology supporting case execution does not have the capabilities needed to bring the Army’s foreign military sales processes up to date with current standards, functionality, and expectations. Instead, it can be characterized as a legacy mainframe system existing in an extended brown-out state precluding any modernization and enhancement efforts to improve business processes. Within FMS-ACES, access to the IT solution for all case execution users will be web browser based. FMS-ACES will leverage COTS products to the maximum extent possible and will be hosted within a DoD-approved, IL4 and FedRAMP certified cloud environment providing secure, near real-time data access.

FMS-ACES depends heavily on a collaborative BPR process with the operational community, acquisition community, and system integrator, as it is the foundation for the implementation of an all-digital system to meet case execution objectives and improve customer service. The FMS-ACES solution will leverage industry best practices as well as adopt OOTB capabilities to the fullest extent possible to meet the capability need. To gain maximum benefit from this effort, the government will work with qualified industry partners to assess process weaknesses, document capability gaps, and recommend opportunities for improvement to determine the best available COTS products to meet FMS-ACES capability needs. This process should not only provide a leap forward in capabilities but should also reduce cost of ownership across investment and sustainment activities.

The current operational environment is defined in the 49 As-Is Operational View 6c (OV-6c) business process models. These process models will be the basis for the BPR effort. The As-Is OV-6c process models (Attachment 005 - FMS-ACES Operational Views) will be assessed and updated (i.e., modified, merged, or deleted) iteratively to describe the To-Be FMS-ACES business processes going forward. This will be an ongoing activity throughout the FMS-ACES program life cycle.

Business Process Reengineering Approach The BPR approach for FMS-ACES will follow an iterative step-by-step process to:

· Review existing As-Is business processes implemented by FMS-ACES stakeholders to identify pain points, bottlenecks, and areas where improvements can be made

· Assess and identify candidate business processes of the procured COTS-based solution for adoption

· Optimize business process workflows within the FMS-ACES solution

· Document the business process workflows in DoDAF architecture product format

· Assess reengineered processes for legal compliance, recommend changes in regulation, policy, and directives, as appropriate to institute new business processes

· Update Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel, Facilities, and Policy (DOTMLPF-P) analysis to identify changes required to align with the defined FMS-ACES business processes

· Implement FMS-ACES business processes within the operational solution

· Monitor business process implementation and adjust as required to achieve required capability and system performance Business Process Reengineering Responsibilities FMS-ACES Program Office

· Facilitate BPR workshops based on agreed to plan(s) collaboratively developed with the solution provider

· Provide qualified personnel to participate in all BPR workshops who have the expertise to perform business process reengineering FMS-ACES Operational Community

· Identify / Prioritize Business Processes for BPR workshops

· Provide subject matter experts to participate in all BPR workshops

· Be prepared to provide examples of data from industry partners or other products to support specific processes under evaluation

· Assess legal compliance for each defined business process and identify impacts and / or recommended required actions

· Utilize FMS-ACES business processes within the operational solution

· Monitor business process implementation and adjust as required to achieve required capability and system performance

· Perform continuous process improvement Solution Provider

· Provide qualified personnel to participate in all BPR workshops to perform BPR activities and describe the business processes within the solution to ensure FMS-ACES processes are properly documented

· Provide COTS products for evaluation and trained operators to demonstrate available processes and procedures

· Implement FMS-ACES business processes within the operational solution

· Guide BPR efforts to recommend out-of-the-box processes wherever possible to ensure product reliability and extensibility over the long term

Program Management Agile Approach FMS-ACES will be delivered using an Agile methodology and the determination of whether the application is developed using Scaled Agile Framework (SAFe), Scrum, a combination, or another Agile methodology will be made in concert with the solution provider and their proposed approach to deliver functionality. FMS-ACES will be developed using DevSecOps principles and implementing a CI/CD pipeline to automate deployment leading to faster remediation of defects and delivery of new functionality.

The program strategy to meet the requirements of DoDI 5000.87 consists of:

· Prototype: FMS-ACES intends to develop/configure a prototype solution during the Planning Phase to,

· assess one or more offeror’s ability to deliver a solution within program parameters

· reduce risk to the Execution Phase MVCR by providing a launchpad for an MVCR warm start

· Multiple Minimum Viable Products (MVPs) during the Execution Phase: It is not anticipated that a single MVP will meet the requirements for MVCR. FMS-ACES intends to leverage multiple, uniquely defined MVPs as checkpoints on the road to delivering the MVCR or subsequent capability releases. These MVPs will be subsets of the capability that is targeted for release, prioritized based on business value and risk, and will likely vary between relatively large and small solution components.

Post-MVCR, the program intends to prioritize the remaining FMS Case Types for subsequent releases to production, incorporating lessons learned from the prototype, MVP, and MVCR. When the FMS-ACES capability eclipses legacy system capability, allowing users to transition completely to FMS-ACES, Minimum Viable Solution (MVS) is achieved. Post-MVS activities will include refinement of the solution, prioritizing lower-level backlog items that were not included in previous releases, and incorporation of emerging needs, acknowledging that the software is never done.

Figure 5 Software Never Done Concept The FMS-ACES Product Roadmap (Figure 4, above) depicts the program events and milestones that are required to accomplish the scope and sequence of the product evolution over time, identifying and defining MVP targets, the Minimum Viable Capability Release (MVCR), and subsequent capability releases. When combined with technical and programmatic inputs from the Product Lead, these milestones will be distilled into a more detailed, and sometimes shorter-term Release Plan which will be used by the development teams to coordinate activities and realize the greatest mission impact first.

Requirements in an Agile environment are usually managed via program, release, and sprint backlogs rather than through formal requirements documents. Due to the complexity and enterprise-wide dependencies that guide FMS-ACES, a hybrid approach will be used that leverages a RTM for technical, operational/non-operational, and enterprise requirements as the foundation for backlog development. The Product Backlog will be created, updated, and maintained in the Government’s Jira instance hosted in the CReATE tool with work items documented in the form of user stories, to accomplish the vision of the Product Roadmap. The Product Owner will actively manage (groom) the program and release backlogs, working with user representatives and other stakeholders to identify the greatest level of detail needed for the highest priority requirements, ensuring that business outcomes are met or exceeded in an iterative way. Development teams will be guided by Release and Sprint plans, selecting items from the backlog to accomplish specified release goals as they design, build, test and deliver potentially shippable increments of configurations/code.

The FMS-ACES Product Roadmap delivers capabilities based on case types processed by USASAC and the ASAE. Using a case type decomposition of the workflows and business processes ensures as functionality is introduced in FMS-ACES, the full workstream can be performed in the application and removed from the legacy CISIL environment. This approach reduces risks associated with split operations in multiple systems.

Figure 6 Notional Product Leadership Components Application architecture, design, development, integration testing, deployments, and maintaining the infrastructure and application will be the responsibility of the solution provider. User acceptance testing will be the responsibility of USASAC and DSCA. The FMS-ACES product lead and Product Office (PO) team (both federal employees and Technical Services support) will monitor, track, provide oversight on integration efforts, track risks, manage the schedule and tasks to ensure the application meets requirements, is efficiently developed and delivered, and meets the PEO EIS standards.

Metrics Metric reporting will be performed by the Product Office in a session that includes representatives from the Operational Community, the Product Office (including the larger Acquisition Community as appropriate), and the Solution Provider. These sessions will be conducted as once-per-sprint events separate from an increment/sprint review and reporting activities will include an aggregate of all data collected up to the most recent sprint. Data and supporting information presented directly from the Agile project management tool is preferred, with slides considered as a backup option due to environmental factors or tool limitations. Reporting from the Agile project management software enforces use of the software to accurately account for value delivered.

The table located in Appendix B and examples in Appendix C establish the minimum set of metrics, supporting data, and corrective action thresholds that will be used to monitor program success.

Solution Provider Deliverables One of the core principles in the Agile manifesto is “Working software over comprehensive documentation”. The intent for solution provider deliverables is aligned to this principle and incorporates the following boundaries:

· Stronger collaboration with the development team to build documentation in line with the software development lifecycle

· Produce minimum viable documentation that is good enough so that it can be used right away Table 2 Solution Provider Deliverables

otherwise below) Frequency

MANAGEMENT

(EDA)

As Required

Performance As Required

TECHNICAL

epic delivery With each epic delivered

As Required

Award As Required

Occurrence As Required

Final Training Materials delivered NLT 30 days prior to the commencement of Training.

As Required

Quarterly

Technical Considerations The Government seeks a solution that minimizes the need for custom code, is not dependent upon proprietary code, has workflows and business processes that can be configured by the user community, complies with current financial and logistical auditing standards, can exchange information with interfacing systems using the appropriate protocols, and is compliant with ZTA standards, ICAM standards, and cybersecurity standards. Key areas the government seeks to understand with respect to technical implementation are:

· Infrastructure and Architecture: The government is looking to leverage commercial cloud infrastructure for FMS-ACES to take advantage of current and provisional Authorizations to Operate (ATOs) for platforms supporting DoD systems already deployed in IL4 and FedRAMP certified cloud environments and to take advantage of lower costs for maintaining platform solutions. The Government seeks a solution that is:

· IL4 and FedRAMP certified and able to achieve a continuous ATO (cATO)

· Compliant with NIST 800-53 r5 standards for a MODERATE non-NSS system

· Compliant with all DoD and Army cybersecurity policies and standards

· Compliant with DoD and Army ICAM requirements leveraging Enterprise Access Management Service-Army (EAMS-A) and Army Master Identity Directory (AMID) applications

· Deployed into multiple availability zones to ensure high availability

· Able to support 1000 concurrent users

· Supported by automated 24/7 system monitoring

· Data Management: Data management is a critical component of the FMS-ACES objectives. The Government seeks a comprehensive data management approach that includes:

· Identifying source and target elements, showcasing the data lineage, profiling the data, cataloging the data, building the data dictionary, creating, and maintaining mapping specifications for interfaces, establishing the relationship, and documenting the logical and physical model.

· Plans and provide pro and cons of the process (batch, real time, API), services, tools, approaches, and solution for building the data pipeline.

· Plans, tools, approaches, and solutions for ensuring quality for FMS-ACES data to include accuracy, completeness, reliability, relevance, and timeliness.

· Plans, approaches, and solutions for ensuring secure data in transit and at rest and restricting data with least privilege access.

· Plans, tools, approaches, and solutions for ensuring accurate integration with interfacing systems, regardless of the language standards they use (i.e., DLMS and MILSTRIP) or the protocol with which they exchange information (i.e., SFTP, SFG, API) as well as ensuring compliance with CEMI standards for the federated Security Cooperation Enterprise.

· Plans, tools, approaches, and solutions for data lifecycle in compliance with National Archives and Records Administration (NARA) data retention standards and provides the ability to restore records from archives to support ad hoc requests for information.

· Plans, tools, approaches, and solutions that support data mesh principles and can be easily integrated into the Army’s data mesh implementation

· Storing and making available financial data in accordance with FIAR / FISCAM standards to support financial audits.

· Storing and making available logistics data to support logistics (requisition, fulfillment, transportation, and receipt) auditing.

· Testing: A comprehensive test strategy that includes:

· Automated and integrated testing (unit tests, regression tests, system integration tests, security scans – both static and dynamic during each sprint and preferably at each build.

· Support for independent test and evaluation of the application conducted by Army Test and Evaluation Command (ATEC) and Join Interoperability Test Command (JITC).

· Unit test coverage and plans for keeping unit tests current.

· The build and support of automated testing and evaluation of the application to ensure comprehensive testing of the system and its interfaces.

· A test plan that addresses testing at each sprint and if possible – each build, deliverables, quality, reports, and processes for defect remediation.

· Automated Dynamic Application Security Testing (DAST) and Static Application Security Testing (SAST) security scans and plans for remediating vulnerabilities, documenting Plan of Action and Milestones (POAMs), and addressing and reducing POAMs in accordance with established DoD standards.

· Plans and processes for integrating security in the DevSecOps processes proposed by the Offeror.

· Plans to incorporate test scripts in the CI/CD workflow.

· Continuous Evolution of Capability: As a product being developed under the Software Acquisition Pathway (DoDI 5000.87), the separation between development, modernization, and enhancement work and operations and maintenance work no longer exists. Instead, systems undergo a continuous evolution of capability. The government seeks an approach for implementing this concept during development of MVCR, through subsequent deliveries, and following delivery of full functionality. The approach should include:

· Delivery of initial MVP as guided by Release and Sprint plans to allow early user feedback on system development.

· Deployment of testable functionality at the end of each sprint following initial MVP, as guided by Sprint plans, to allow early user feedback on system development.

· Plans and approaches that are CSP independent.

· The ability to ensure the system is on the most current version of libraries and modules while accounting for dependencies on other systems and 3rd party libraries and tools.

· Modifying configurations and systems to account for changes in LRPDs that cannot be managed by user changes to configurations.

· System architecture and design such that it has room for integration, data sharing, and future enhancements.

· Remediating issues identified in the production system.

· A data pipeline that is template driven through Infrastructure as code (IaC) and supports a CSP independent CI/CD pipeline.

· Timeline: The government seeks a timeline for the incremental delivery of business functionality that allows the stakeholders to begin using FMS-ACES as soon as possible. The timeline should include:

· Implementation timelines for delivery of the notional roadmap or the Offeror proposed roadmap.

· Lines of effort, team composition, measures, and metrics for delivering the Offeror’s solution on the proposed timeline

· Milestones and decision points

· Resources, constraints, and dependencies required to achieve each milestone

Appendix A Acronyms Acronym (* shown in figures) Definition