B08.03 Answers to Questions - W912HQ24R0013 - NNOMPEAS.docx

Answers to Questions for NNOMPEAS System Maintenance & Enhancements

1. Who is the Incumbent for this Contract, and what’s the contract value?

You may review the contract action report for contract W912HQ23P0134 in FPDS-NG for this information.

2. For the scope of the work variance from the last contract period, what is the additional scope of work added from the previous contract period across the task areas [Task 3.1 to Task 3.7 – referring to PWS document]?

The scope of work in many ways is similar as many of the efforts entail annual update of input data and information and general system maintenance for maintaining performance (speed of compilations\computations) and revision of user interface screens as needed, etc. What is different is the level of effort likely devoted to migration to a cloud environment and additions or enhancements for moving further with value to the nation estimations and reporting.

3. What are the precise versions of (OS) Linux/RHEL and DB? (e.g., 19.23 for Oracle 19c)?

The database (DB) software and version is Oracle 19.23 with potential or likelihood of consideration and need to facilitate migration or update to Oracle 23 if warranted (in part to potentially support some measure of spatial or GIS applications or integration) while he operating system (OS) is Oracle’s current version of Linux as opposed to Red-Hat Linux.

4. Is it a multi-tenant architecture? Does the Database have pluggable DBs?

This depends on how you define multi-tenant architecture or system. The NNOMPEAS application is only one of many largely self-contained modules under an overall umbrella cloud system which houses or governs other modules or applications and databases, and it must comply with requirements for security and integrity for the overall umbrella system and architecture. In addition, it also shares some of the underlying functional software. For example, the Oracle database system that drives a significant part of NNOMPEAS also supports other applications. When this underlying shared database software system is stood down for maintenance or there is an outage, all applications using subject software application(s) are impacted. In the contexts described, one may consider it a multi-tenant system(?).

5. Does the system need a backward compatibility setup as part of the upgrade?

Generally, backwards capability is not required. Each time the system is migrated to updated software all of the code and integrated data storage, handling, and formatting are migrated along with it, thus systems and data are all operating under current compatible versions of software for operating system and database management or operation. As such there are generally no legacy data structures currently of issue. Occasionally in the past we have restructured the data structure to enable more varied or enhanced use for computational or numerical quantitative relationships, but this has been seldom undertaken and is not a specification or requirement of the subject or current PWS or work requirement.

6. How big is the DB or the total volume? (GB/TB)?

The current underlying database volume is approximately 360 GB with accommodation of about 19 years of data. Data is added each year with each successive year varying in volume or size but generally growing slightly larger over time based on the volume of trade movements accounted for in each annual update.

7. What is the current data model complexity? (Number of tables, relationships, etc.)

The underlying database tables presently number 422. User interface display tables are variable depending on the extent of query detail and can be as few as one to several hundred for displaying formatted data for evaluation and interpretation. This number is expected to increase over time as additional functions or statistics may or are formulated for output.

8. Are there any legacy data structures that need to be updated or migrated?

See response to question 5; preceding.

9. What is the total number of DB objects (counts with respect to schemas)?

The present number of underlying database objects is approximately 93,955 with expectation these may or will increase over time as additional functions or statistics may or are formulated for output.

10. Are we expecting new feeds or headers to be loaded in the scope of the work, or is it just adding a few fields to the existing feeds which are being loaded?

Generally, the underlying dataset and format display headers are at this point in time considered stable but are subject to change based on any desired enhancements or adaptation of the system. Feeds and fields for data and information are also largely stable but sometimes intake formatting changes and needs to be edited or amended to facilitate intake of needed data and information.

11. What is the expected growth rate of data over the next 3-5 years?

See response to question 6; preceding.

12. Are there any specific performance bottlenecks in the current system?

This question is somewhat “wide open” or vague but will attempt to provide information herein on best efforts basis. Traditionally, the main constraints on the system have been server hardware and memory availability which with on-premise systems have been somewhat “rigid” or fixed across a given period in time. When large compilations or compute-intensive queries were executed response would tend to significantly slow or even time out due to competing network resources. This is a significant part of the justification for migration to a cloud environment where dynamic or dynamically-accommodating architecture should reduce or lessen such constraints.

13. Does the requirement ask us to create a new schema altogether from NNOMPEAS to support the functionality of O&M (View/Extract)?

Presently this is not envisioned as such though schemas may need to be somewhat altered or amended as migration to the cloud is completed depending on any impacting requirements for standardization (where or if applicable).

14. What are the specific requirements for the future cloud migration (Impact level/Risk Mgmt)?

The requirements for cloud migration are for an Impact Level 4 (IL4) environment accommodating data and information assessed as CUI (controlled unclassified information). Most of this information accordingly is not made available to the public. or any other Federal agencies. Its distribution even within USACE at the detail level is based on a need-to-know basis and is governed by non-disclosure (NDA) agreements and non-alternative use agreements (NAUAs), and access to the system is via verification of authorized user and requisite individual identification. Respective to (additional) measures for compliance with the risk management framework, code is scanned two to four times annually and identified vulnerabilities for intrusion, unauthorized access, and general environment compatibility\stability must be corrected within fifteen (15) calendar days of each scan for maintenance\continuance of Authorization to Operate (ATO).

15. Is there a preferred cloud service provider, or should a case study be done for major providers (AWS/Azure/GCP)?

The current preferred commercial cloud service provider is Amazon Web Services (AWS) as opposed to Microsoft/Azure or Google/GCP. This may change at some course in the future but this is the responsibility of overall IT management provided to the NNOMPEAS application which is essentially only one of many modules or tenants under subject cloud systems development and management. As such a case study is neither required nor requested in support of or in association with, the subject PWS.

16. Are there any specific USACE or DoD security requirements beyond the mentioned IL4?

See response(s) to question 14; preceding; questions 17 and 18 following along with general security requirements common to all DoD systems.

17. What is the current user authentication and authorization mechanism?

The current mechanism for user authentication and authorization for access and use is input of an employee identification code and database system password. This however is being migrated toward use of an individually-assigned common access card (CAC) and associated personal identification number (PIN), and individual password.

18. Are there any data masking or anonymization requirements for sensitive data?

Yes. As an example, there are differing levels of usership and associated privileges. Some of these levels of usership allow only the viewing of highly aggregated data while others allow the viewing of data at the lowest level. Also there may be requirements for aggregation of data for output or export when the data or information is used internal to USACE.

19. Are there any APIs that need to be maintained or updated?

Yes; there are 23 APIs that control or manage the encapsulation of complexity of the system and the number may increase as changes are made to the system over time.

20. Are there any specific data exchange formats or protocols that need to be supported?

Yes; general database flat file for intake of data and information and basic CSV for export or extraction of data via the underlying database application.

21. How many environments are defined in the current setup? (Expecting DEV, TEST, INTG, and PROD).

The current set-up is in transition from on-premise systems to cloud-based system residence with expected availability of development, test(ing), and production\deployment environments to be in place for or starting in early (end of October to early November) FY 2025. To present knowledge or understanding a separate integration(?) environment is not to be provided or considered necessary given functional set-up as currently being developed for the test(ing) and production\deployment environments. All of these environments are to be cloud-resident commensurate with requirements and specifications for an impact level (IL) 4 environment.

22. What is the current backup and disaster recovery strategy?

Specific to the direct management and support of the system itself, basically ongoing updated source code retention or duplicative back-up. Outside of this, procedures and protocols are still being formulated for the cloud-based system or umbrella\overall multiple-module environment. Refer to response to question 4; preceding, for further context and explanation.

23. What is the current deployment and release process?

In terms of technical functioning for use, the current deployment and release process generally involves environment compatibility and technical use or application testing (while in a supporting test environment; by the programmer and the technical point of contact (TPOC) for oversight, respectively) of the system combined with further practical or applied review and technical use testing by specified designated test users. Technical deficiencies (if any for a given release) are corrected and retested before migration to production\deployment. If a release constitutes what is considered a significant change in source code or underlying routines and protocols, the source code may be subject to scanning or re-scanning for vulnerabilities and further requisite correction, or adjustment as needed for compliance with specifications for continuance of the associated Authorization to Operate (ATO).

24. Are there any specific maintenance windows or change management processes to be aware of?

Yes; The primary intake of annual update of needed data and information is usually about mid fiscal year (end of February to end of March each year), temporary short-term stand-down or lock-down of systems at the end of the fiscal year (usually only for a relative few days during end of September and the beginning of October), along with security review and code scans which may be conducted quarterly or even more often depending on assessed external threat or risk for unauthorized access or potential breach based on DOD evaluation external communications or electronic environment.

25. How many external systems does NNOMPEAS interface with?

Outside of its umbrella and immediate operating system environments and supporting software applications, basically none. It does interface with external datafiles for the intake of data and information which are largely made available in flat file dataset\database format or similar thereof.

26. What are the current data quality issues, if any?

Given the nature of the data handled and how it is often initially gathered, we are sometimes dealing with simple recording or reporting error. Knowledge of the subject data and information and how it is used for USACE purposes is therefore critical to quality management of the system in terms of what is submitted for intake versus how it is used or applied for analytical output(s).

27. Are there any data governance policies or data stewardship processes in place?

Yes; depending on whether for protection of sensitive or proprietary data and information assessed as CUI, whether commercially acquired data and information subject to requisite agreements or other data and information accepted or provided subject to agreements, and reasonable requirements for retention and duplicative back-up of data and information, and reasonable measures for unintentional and unauthorized access or disclosure.

28. What are the most common user complaints or feature requests for the current system?

The most common user complaint(s)s concerning the system are the time lag for some of the primary base input data annually uploaded and employed or integrated into the system. Respective data is provided by the Waterborne Commerce Statistics Center (WCSC) of USACE and its schedule of or for provision is not something of jurisdiction for the NNOMPEAS system.

29. How many active users does the system currently have?

The data and information is for a specialized realm of use and application, largely associated with analysis and evaluation of waterborne navigation by USACE. Correspondingly, the system is structured to support approximately thirty to sixty users with expectation that no more than approximately one-third to one-half would need to access or use the system simultaneously at any given time or instance of usage.

30. What is the current testing strategy (unit, integration, and user acceptance tests)?

Refer to response for question 23; preceding, concerning testing and verification for environment compatibility and functioning, and valid functioning for technical use by end users.

31. Is there an existing test environment and test data set?

Yes, there exists both a compatible test environment and test data set compatible with existing functions and capabilities of the system.

32. Are there any automated testing tools currently in use?

Standardized automated testing tools are used by the information management and technology (IM\IT) assessors for source code scans and assessment of vulnerabilities or environment incompatibilities. Limited function-specific testing methods devised specific to the application are sometimes applied to the verification of data, information and algorithms for compilations and computations, and associated accuracy or validity of resulting output.

33. What is the current state of system documentation?

System documentation is at a minimally acceptable level assuming reasonably comprehensive technical knowledge of both software\source code generation and function, and technical knowledge of USACE\NED analytical and evaluation methods for waterborne navigation (i.e., what the software or source code does versus the why or objectives of its functioning.

34. What is the current process for user training and support?

The current process of user training and support is primarily provided by the technical point of contact (TPOC) for the application through provision of a personal orientation to\with new users and via limited electronic documentation for functions or use-options within the user interface system. With this, most users familiar with navigation economics and National Economic Development (NED) evaluation procedures can typically or intuitively develop an extended working base of knowledge as needed by ongoing access and use of the system or application. A more formal user manual or technical guide is in process but its development is subject to resources as available and is not specifically a part or specification of the subject PWS as priorities are for ongoing technical development of the system. The supporting programmer however may be required to add or edit instructions within the user interface system where or if new tables or functions are added, etc. but experience indicates these are considered minor taskings within the specifications of ongoing maintenance or where\if specified by the PWS, technical improvements.

35. Will there be a need for updated user manuals or training materials?

Not specifically under the subject PWS; refer to question 34; preceding.

36. Are there any known future requirements or integrations planned beyond this project?

See response to question 38, following.

37. Is there a long-term vision for NNOMPEAS that might impact architectural decisions?

The basic interim and long-term vision or foreseeable path(s) of what needs to be done in terms of data and information analysis and application itself has long been though through and primary objectives determined. The issues are how best to achieve the objectives and execute or undertake requirements or specifications for supporting technical efforts. Beyond this, the posed question arguably is somewhat difficult to answer in context that systems are under continuous review over time with possibility of either minimal support at an acceptable level of functioning or further enhancement of an existing system, or migration toward another significantly or measurably different system. The path or course undertaken simply depends on the nature and cost-effectiveness of evolving information technology combined with availability and specifications for data and information of interest, and analytical needs or purpose that may change or vary over time, such as recent efforts to migrate to a cloud environment, the ability to employ AI or machine learning algorithms, or greater integration of capabilities for GIS\AIS and spatial analysis for example. In summary what needs to be done in terms of the analytics is largely known, but the “how to get there” is always subject to adaptation or change with practical considerations for budgetary resources, cost-effectiveness, and acceptable fulfillment of technical needs at any given time or fiscal cycle.

End of questions and responses