Project

General

Profile

Actions

Task #107

closed

Simulation 1- RAM pilot - data Data ingestion and migration (RAM HAS NO API/NOT CLOUD NATIVE)

Added by Lloyd Osafo over 2 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
High
Assignee:
Start date:
09/30/2022
Due date:
08/02/2023
% Done:

100%

Estimated time:
240.00 h
Spent time:

Description

Reviewed- RAM documentation, Identified key environment variable infrastructure and key services to integrate ORE to. RAM does not have an API and would therefore requires ORE data adapter to pull from the RAM back end database to storage existing ~ 5,000 documents it currently stores.


Files

RAM_Model_Request.pdf (180 KB) RAM_Model_Request.pdf RAM meta data Model Request Lloyd Osafo, 11/02/2022 05:20 PM
Notional_ORE_RAM_Allocation_final_18nov2022.pdf (2.34 MB) Notional_ORE_RAM_Allocation_final_18nov2022.pdf Jacob Halle, 01/17/2023 08:40 PM
ORE-Attribute files.png (112 KB) ORE-Attribute files.png Jacob Halle, 01/17/2023 08:52 PM
ORE- Document view attributes info.png (304 KB) ORE- Document view attributes info.png Jacob Halle, 01/17/2023 08:52 PM
ORE- Attribute viewing icon feature.png (902 KB) ORE- Attribute viewing icon feature.png Jacob Halle, 01/17/2023 08:52 PM
Actions #1

Updated by Lloyd Osafo over 2 years ago

  • Status changed from New to In Progress
Actions #2

Updated by Doug Fraser over 2 years ago

  • Subject changed from RAM Integration to RAM pilot - data Integration and migration
Actions #3

Updated by Lloyd Osafo over 2 years ago

  • Subject changed from RAM pilot - data Integration and migration to RAM pilot - data Data ingestion and migration

Simulation Activities

Scope of simulation-
1.) Identify and prototype approach to Extract existing ~5,000 content/documents from RAM ( 2 Twelve awaiting technical data requests related to the application)
2.) Identify engineering technical approach to ingest content of the RAM into the ORE (Upon receipt of the technical configuration list provided below action is on hold)
2a.) awaiting detail questions provided to Rob Sayson/ and Government to provide so 2 Twelve can conduct analysis and provide what features can be allocated to the ORE and which ones can be allocated to other solutions ie. Service now, office 365, nautobot for NDP, and ORE.

3.) 2 Twelve will provide insights and recommendations for functions that can be re allocated from the RAM to other services, such as Servicenow/ 0365 collaboration since we are familiar with those services upon further understanding of the operational use cases for RAM to support how engineering controls the operational environment with these system sub system "installation" documents.

Success Criteria- approach for extraction of the ~5,000 documents in the RAM into the ORE
Providing functional allocation to other services including the ORE, service now, office 365 , nautobot

If features in RAM are a Must have, workflow is not in existing task order, and Government desires function to be developed in ORE, further discussion and contract mod of the specification must be made to ensure the equitable adjustment of the specs for the functionality that is desired to be natively developed in the ORE.
Phase 1-
Documentation review of the RAM ( provided 14 Sept 2022)
Additional information details below on the data and permission rights requested on (21st Oct 2022) below. Awaiting details from below which would provide 2 Twelve further fidelity on time-line, functionality that could be allocated to ORE, Nautobot, Service now, o365.

NDP ORE Data Extraction Survey for RAM-
We would like to understand more about the system or application that will be integrated with the NDP ORE in order to speed up the effort. It is OK to not be able to answer all the questions, please provide as much as you are able to.
Question Response
*Key Logistics Details

KL-1 Who are the technical admin point of contacts for the system?
KL-2 Where is the system hosted?
KL-3 What is the URL path?
KL-4 What secrets/tokens/cryptographic standard is desired to be used to connect to the system?
*Key Systems Details
KS-1 Does the data that resides in the system originate from other external system(s)? If so, please list the external system(s)
KS-2 How does the system store the data? e.g. Database, File store, etc. Please be specific as possible
KS-3 Does the system allow its capabilities to be consumed via API or some other non-user facing process?
KS-4 Does the system allow its data to be exported?
KS-5 Does the data in the system get updated in real-time? E.g. its continuously changing or information goes stale very quickly
KS-6 Whom or what groups are the major users of the system?
*Key Data Details
KD-1 What contents in the system is desired to be synchronized to the NDP ORE?
KD-2 What data in the system would be considered related to system engineering management data or artifacts?
KD-3 What data sources does the system work with?
KD-4 Is the data structured or unstructured? Please be specific as possible
KD-5 Is it machine generated or user generated data?
KD-6 What are you getting from the data?
KD-7 What do you not get from the data that you need?
KD-8 Do you have to repeatedly cleanse the data?
KD-9 Will there be a point of contact who will be able to walk us through the details of the data?
*Key Processes Details
KP-1 How do the majority of your users use the system?
KP-2 How do you share/socialize data with other stakeholders or groups in your organization?
KP-3 Are there any business processes or user processes available that can be shared to help us understand more about your system?
KP-4 What are the functionalities that are required?

Email provided to Gov requesting additional information for RAM integration to leverage as input into the engineering schedule. Awaiting Information from Gov and service provider attached

*Rob, *
We reviewed the PDF sent and unfortunately it is too high level for it to be useful to the NDP ORE at this time.

In the case of RAM, we are trying to configure the ORE so that it can readily archive documents and videos from RAM along with the associated metadata for such files. A role of the ORE is to enable the real-time governance of the system engineering management (SEM) process. So it will be a consumer of many data sources where SEM related data is produced and will provide a unifying overlay (single pane of glass) for insights into the progress and quality of equities under the PEO Digital SEM portfolio.

I found a screenshot from one of the work instructions for the RAM that I've marked up to show exactly what data we were asking for in last week's conf call. Please see attached PDF.

In essence, we are looking for the values in the dropdowns and select boxes when a user of RAM uploads an asset/artifact. The reason we need this is to ensure we have all the necessary context (metadata) of the things that are pushed/pulled into the ORE. In the case of RAM, just having the files would be missing a lot of the who/where/when/why aspects that goes with the files. You mentioned that you do not have edit/add rights to the RAM and that the service provider is in control of it -- so you may not be the person that can track down the values for us. If that is the case, please provide us a RAM user or a POC of the RAM service provider so that we may work with them to capture all the values in those upload/edit screens.

Actions #4

Updated by Lloyd Osafo over 2 years ago

  • % Done changed from 0 to 20
Actions #5

Updated by Lloyd Osafo over 2 years ago

  • Subject changed from RAM pilot - data Data ingestion and migration to RAM pilot - data Data ingestion and migration (RAM HAS NO API/NOT CLOUD NATIVE)
Actions #6

Updated by Lloyd Osafo over 2 years ago

  • Subject changed from RAM pilot - data Data ingestion and migration (RAM HAS NO API/NOT CLOUD NATIVE) to SIMULATION 1- RAM pilot - data Data ingestion and migration (RAM HAS NO API/NOT CLOUD NATIVE)
Actions #7

Updated by Doug Fraser over 2 years ago

  • Start date changed from 08/29/2022 to 09/30/2022
Actions #8

Updated by Doug Fraser over 2 years ago

  • Project changed from 4 to Simulation Activities
Actions #9

Updated by Lloyd Osafo over 2 years ago

  • Assignee set to Tom Eden
Actions #10

Updated by Doug Fraser over 2 years ago

  • Subject changed from SIMULATION 1- RAM pilot - data Data ingestion and migration (RAM HAS NO API/NOT CLOUD NATIVE) to Simulation 1- RAM pilot - data Data ingestion and migration (RAM HAS NO API/NOT CLOUD NATIVE)
Actions #12

Updated by Lloyd Osafo over 2 years ago

  • % Done changed from 20 to 30
Actions #13

Updated by Lloyd Osafo over 2 years ago

  • % Done changed from 30 to 10
Actions #14

Updated by Doug Fraser about 2 years ago

  • % Done changed from 10 to 30
  • Estimated time set to 240.00 h
Actions #15

Updated by Jacob Halle about 2 years ago

Planned architecture for implementation for extracting existing artifacts from existing RAM into the ORE is attached. Development team established in the ORE the different data attribute fields to enable retrieval of content from the RAM to be rendered and viewed in the ORE.

Actions #16

Updated by Jacob Halle about 2 years ago

  • % Done changed from 30 to 50
Actions #17

Updated by Jacob Halle about 2 years ago

  • Due date changed from 03/01/2023 to 06/01/2023
Actions #18

Updated by Jacob Halle about 2 years ago

Uploaded screenshot images of a recent release and development of the icon and attributes associated with documents to ensure extraction for RAM files maintain their metadata tags as in RAM to be viewed in the ORE.

Actions #19

Updated by Jacob Halle almost 2 years ago

  • Tracker changed from Feature to Task
Actions #20

Updated by Jacob Halle almost 2 years ago

  • Due date changed from 06/01/2023 to 08/02/2023
Actions #21

Updated by Jacob Halle over 1 year ago

  • Status changed from In Progress to Closed
  • % Done changed from 50 to 100

The ORE was updated to now have the ability to ingest any data from the RAM. The ORE is able to upload any files (eg documents, CAD, etc.) necessary from the RAM, so this simulation has been completed according to specifications.

Actions

Also available in: Atom PDF