Strategie per la gestione dei dati legacy per un'impresa di medie dimensioni

1

Lavoro per un'azienda manifatturiera del mercato medio con circa 1700 dipendenti interni e circa 7000 utenti esterni (dipendenti dei nostri clienti). Siamo cresciuti attraverso l'acquisizione, il che significa che abbiamo molti sistemi separati che servono la stessa funzione per diverse parti della nostra attività (due ERP, 3 CRM, 3 applicazioni di e-commerce, dozzine di applicazioni BPM, dozzine di varie app mobili, decine di dispositivi IoT , ecc.)

Sto diventando sempre più preoccupato per i nostri dati. Il prodotto che produciamo ha un ciclo di vita di 30 anni e i nostri clienti si aspettano che i dati del 1980 siano accessibili in ogni momento. Probabilmente abbiamo 50 milioni di ordini seduti in 8 sistemi diversi su 8 piattaforme diverse. Abbiamo dati di credito seduti in forse 5 sistemi diversi su 5 diverse piattaforme, ecc. Gli ordini / crediti / ecc. Filtrano tutti attraverso il nostro vecchio ERP AS400 ma solo le informazioni finanziarie, il resto è seduto nel sistema che lo ha raccolto. Altrettanto preoccupante è che abbiamo circa 10 milioni di file di progettazione tecnica sparsi su varie unità di rete senza alcun tipo di gerarchia o capacità di query.

Abbiamo un architetto di dati che sta costruendo un data warehouse per i rapporti, ma non è entusiasta di utilizzare quel data warehouse come una "legacy lookup" che può essere accessibile ai dipendenti in prima linea.

Mi chiedo se qualcuno condivida alcune strategie per gestire questi dati. Le mie domande principali sono.

  1. Quali sono i vantaggi e i rischi di lasciare i dati legacy nel suo stato attuale, quindi accrudendoli attraverso un qualche tipo di sistema SOA / BPEL rispetto a fare ETL e metterlo in scena in una posizione centrale
  2. Con quale frequenza i dati correnti devono essere estratti (se non del tutto) in un DB centralizzato?
  3. È meglio provare e ottenere questi dati in uno schema uniforme o semplicemente mantenerlo così com'è e separare le GUI in base agli schemi?
  4. Esistono soluzioni COT formiche che possono aiutare?
  5. Qualche suggerimento / trucchetto per l'interfacciamento con una varietà di database diversi (DB2, SQL Server, Oracle 11g / 12c, MySQL, ecc.)
  6. Eventuali suggerimenti / trucchi di rete per impedire ai processi ETL di distruggere la nostra rete?
  7. Il sistema di archiviazione e recupero dei dati testuali dovrebbe essere una soluzione diversa dai dati dei file?

Sto solo cercando di capire da dove cominciare.

    
posta Chris Maggiulli 11.05.2018 - 02:56
fonte

1 risposta

1

Ovviamente sarebbe tecnicamente bello avere tutto su un singolo sistema moderno. Inoltre, ci sarebbero molti vantaggi, risparmi sui costi dovuti al ritiro dei sistemi legacy, riduzione dei rischi di protezione dei dati ecc.

Tuttavia è un enorme compito di ritirare anche un singolo sistema e qui si hanno più sistemi interdipendenti da molte acquisizioni.

Nella mia esperienza in cerca di una soluzione di compromesso, in cui si interfaccia il nuovo sistema con il vecchio, è a basso rischio, ma non si rendono conto dei benefici, che sono ottenuti principalmente da non avere il vecchio sistema, piuttosto che avere i dati sul nuovo sistema.

Direi che le cose fondamentali per un progetto di migrazione di successo sono:

  • Processo di scoperta attento per mappare tutti i sistemi e i processi interessati
  • Un (lungo) cambiamento nel periodo in cui entrambi i sistemi sono in funzione contemporaneamente.
  • Consentire la migrazione di sottoinsiemi di dati e iniziare con un piccolo gruppo di clienti "test"
  • Test completo dei dati migrati. Verifica rispetto a ciò che dice il vecchio sistema.
risposta data 11.05.2018 - 11:42
fonte

Leggi altre domande sui tag