Operazione: Analisi asset esistente
Questa attività identifica gli elementi di progettazione di una soluzione orientata al servizio in termini di servizi e partizioni e documenta la specifica iniziale di tali servizi.
Discipline: Analisi e progettazione
Scopo
  • Identificare gli elementi di progettazione di una soluzione orientata al servizio in termini di servizi e partizioni.
  • Documentare la specifica iniziale dei servizi.
  • Determinare le dipendenze iniziali e la comunicazione tra i servizi.
Relazioni
Descrizione principale
L'analisi dell'asset esistente è il processo di utilizzo degli asset esistenti (ad esempio sistemi esistenti come le applicazioni impacchettate o personalizzate) e degli standard del settore, dei modelli e degli asset per soddisfare la realizzazione dei servizi. L'utilizzo di un approccio dal basso in alto, Analisi asset esistente identifica e convalida i servizi candidati, i componenti ed i flussi. I limiti tecnici relativi ai sistemi esistenti dovrebbero essere valutati il prima possibile a scopo di gestione del rischio. In questo modo conducendo la fattibilità tecnica delle decisioni di realizzazione del servizio è spesso eseguita prima possibile dopo o durante l'analisi dell'asset esistente.
Passi
Identificazione dei servizi candidati dalle applicazioni personalizzate

Vengono utilizzate due procedure secondarie per identificare la funzionalità fornita dalle applicazioni esistenti. La prima procedura secondaria, associazione a granularità complessa, associa i processi di business al portafoglio delle applicazioni esistenti. La seconda procedura secondaria, associazione a granularità semplice, coinvolge l'associazione di un servizio ad una transazione specifica o un processo di batch nella applicazione legacy. L'associazione a granularità semplice viene seguita durante la specifica del servizio.

Lo scopo dell'associazione a granularità complessa è di derivare l'associazione preliminare, iniziale delle funzioni di business dai servizi.

Per identificare i servizi candidati dalla funzionalità nelle applicazioni esistenti, è necessario comprendere il rapporto tra il processo di business e le applicazioni esistenti. Questo può essere descritto come associazione a granularità complessa. Tale associazione è tra le attività ed i processi di business e le funzioni di business delle applicazioni esistenti come di seguito mostrato.

Per catturare i rapporti tra i processi di business e le applicazioni esistenti, eseguire le seguenti procedure di associazione a granularità complessa.

  1. Comprendere le funzioni di business supportate da ogni applicazione.  In genere una funzione di business può essere associata ad un'attività in un processo di business.
  2. Registrare gli attributi delle applicazioni esistenti in termini di tecnologie utilizzate, stili di architettura ecc.
  3. Identificare le applicazioni che eseguono i servizi comuni.

Analisi del portafoglio delle associazioni e applicazioni a granularità complessa

La comprensione del valore di business e della qualità tecnica delle applicazioni esistenti aiuta a creare un piano di trasformazione con la priorità più alta data ai servizi di valore più alto e di valutare i rischi di ambito e tecnici in base alle qualità tecniche dell'applicazione, ad esempio, il grado di accoppiamento.

L'analisi del portafoglio dell'applicazione fornisce un ambito ed i limiti per l'associazione a granularità complessa. Ad esempio, le applicazioni con minimo valore di business o basso valore tecnico che sono etichettate come obsolete, probabilmente non sarebbero nell'ambito per l'identificazione del servizio candidato.

L'analisi del portafoglio delle applicazioni, se eseguita, potrebbe fornire informazioni relative ai servizi esistenti per l'associazione a granularità complessa. L'output di questa analisi sono i servizi candidati come di seguito illustrato.

Identificazione dei servizi candidati dalle applicazioni impacchettate

I pacchetti ISV (Independent Software Vendor) sono comunemente implementati per abilitare i sistemi secondari e/o i componenti del servizio in un'organizzazione. Ad esempio, i pacchetti ISV ERP (Enterprise Resource Planning), come quelli offerti da SAP, PeopleSoft e Oracle, sono spesso implementati come sistemi completi che comprendono sottosistemi multipli che supportano completamente uno o più domini in un'organizzazione. Questa sezione descrive una serie di azioni che consentono al professionista di identificare la funzionalità ed i servizi candidati nei pacchetti ISV esistenti. Questa analisi consente ai prodotti di lavoro Matrice funzione/sistema business, Catalogo delle regole di business e Modello di servizio di essere popolati in base alle funzioni dei pacchetti ISV esistenti.

Nota: Poiché ogni pacchetto ISV è diverso, non è possibile sviluppare un approccio di prospettiva dettagliati per ognuno. Le seguenti attività descrivono un approccio generico ed un insieme generico di attività che:

  • Identificano i servizi candidati nei pacchetti ISV.
  • Identificano le caratteristiche di alto livello dei pacchetti ISV che verranno considerato durante la realizzazione del servizio.

Identificazione pacchetto ISV

Idealmente, i pacchetti ISV per i domini dell'ambito ed i componenti business dovrebbero essere stati identificati nel Sistema CBM nell'input Business Component Overlay (o equivalente). Questo risulta in un elenco di pacchetti ISV che abilitano la funzione nei componenti business specifici nell'ambito della soluzione prevista. Se questo input è mancante, i pacchetti ISV che supportano i domini inseriti nell'ambito ed i componenti di business dovranno essere identificati e associati ai componenti di business.

Notare che alcuni pacchetti ISV, come SAP, PeopleSoft e Oracle, contengono un numero di moduli principali e facoltativi. Ad esempio, SAP dispone di un modello di produzione, un modulo di risorse umane e uno di gestione del rapporto con i clienti. In questi casi, è importante specificare quali moduli specifici dei pacchetti ISV si stanno utilizzando. Questo darà come risultato un'analisi più attenta che farà risparmiare tempo ed evitare un proliferazione dei servizi non necessaria.

Divisione per categorie del pacchetto ISV

La divisione per categorie dei pacchetti ISV fornice una visione di alto livello delle caratteristiche importanti da considerare durante la realizzazione del servizio (questo si applica ai componenti funzionali e tecnici. Gli ISV possono essere suddivisi in categorie come ISV di livello 1, 2 o 3 in base alle caratteristiche come le competenze principali, la dimensione e il ricavo come riepilogato nella tabella 10. Notare in particolare gli aspetti dell'impatto tecnico e di business.

Categoria ISV ISV Livello 1 ISV livello 2 e 3
Descrizione Gli ISV ampi come i vendor ERP (Enterprise Resource Planning) che forniscono applicazioni impacchettate gestiscono le risorse e le operazioni principali. Gli ISV da medi a più piccoli che tendono ad offrire soluzioni di business verticali specifiche del settore
Caratteristiche
  • Applicazioni integrate, a più moduli e a settori incrociati per la pianificazione del prodotto, l'acquisto delle parti, la conservazione degli inventari, l'interazione con i fornitori, la fornitura di assistenza clienti e la traccia degli ordini.
  • Possono anche includere moduli di applicazione per gli aspetti finanziari e di risorse umane di un'azienda.
  • In genere estendono i componenti aziendali multipli e anche i domini in un'associazione CBM
  • Sono spesso impacchettati con il proprio middleware del proprietario, la protezione e altri componenti tecnici
  • In genere abilitano sottosistemi verticali specifici del settore che supportano una funzione specifica in un'azienda.
  • In genere documentano le interfacce di business con uno o più ISV di Livello 1.
  • Di solito contenuti in un dominio CBM ed un piccolo numero di componenti di business.
  • Di solito si basa su middleware esterni di terze parti e altri componenti tecnici.
  • Possono avere i loro componenti di sicurezza.
Impatto tecnico Dati le grandi "impronte", queste ISV potrebbero avere un'influenza significativa sull'architettura tecnica e gli standard utilizzati in un'organizzazione. In questi casi, queste influenze sono identificate e considerate durante la realizzazione del servizio.
Il middleware e gli altri componenti tecnici, come l'autenticazione e la registrazione, dovranno essere considerati durante la realizzazione del servizio.
Questi ISV in genere hanno meno influenza strutturale in una grande organizzazione, ma in una più piccola, un'organizzazione specifica del settore altamente specializzata, questi anche possono avere un'influenza significativa sulla realizzazione del servizio.
Questi pacchetti in genere non forniscono il proprio middleware o i componenti tecnici. Questi si possono affidare al middleware di terze parti e ai componenti tecnici - oppure possono affidarsi a quelli forniti da un ISV di Livello 1. Alcuni ISV più piccoli potrebbero non fornire le interfacce ai componenti tecnici. Questi si possono affidare al middleware di terze parti e ai componenti tecnici - oppure possono affidarsi a quelli forniti da un ISV di Livello 1. Alcuni ISV più piccoli potrebbero non fornire le interfacce ai componenti tecnici.
Impatto sul business Le organizzazioni che hanno investito in ISV di Livello 1 frequentemente hanno una predisposizione ad utilizzare questi pacchetti al massimo. In questi casi, c'è una forte propensione ad utilizzare questi pacchetti esistenti per realizzare i servizi e anche abilitare nuovi servizi. Poiché questi pacchetti tendono ad abilitare un ambito più piccolo di funzionalità, c'è meno propensione e opportunità di estendere questi pacchetti per realizzare nuovi servizi.
Esempi SAP, Siebel, Peoplesoft, Oracle Financials Manugistics, Provia, Evoke/TD>

Poiché i pacchetti ISV sono utilizzati virtualmente in tutte le organizzazioni, la maggior parte delle soluzioni orientate al servizio incorporano i servizi realizzati tramite i componenti del servizio in base ai pacchetti ISV. La suddivisione in categorie di questi pacchetti ISV consente al professionista di comprendere il ruolo e la relativa importanza di questi pacchetti nella soluzione SOA e di identificare le caratteristiche funzionali che verranno considerate durante la realizzazione del servizio.

Per ogni pacchetto ISV, una conoscenza nelle seguenti aree viene ottenuta tramite l'analisi eseguita durante l'organizzazione:

  1. Una conoscenza del significato e l'influenza di questo pacchetto ISV nell'azienda.
  2. La propensione a realizzare tutti i nuovi servizi tramite questo pacchetto ISV.
  3. Gli standard dell'architettura ed i componenti tecnici utilizzati nel pacchetto ISV e il loro ruolo nell'azienda.
  4. Una conoscenza del middleware e dei componenti tecnici compatibili con il pacchetto ISV.

Analisi opzioni per l'accesso ai servizi nei pacchetti ISV

Questa fase identifica i meccanismi per i quali è possibile accedere alle funzioni nei pacchetti ISV (ad esempio gli aspetti del pacchetto direttamente relativi all'esposizione e alla realizzazione del servizio). Queste informazioni vengono utilizzate per aiutare ad identificare i servizi candidati nei pacchetti ISV (nella fase successiva) e verranno utilizzate anche successivamente per valutare la fattibilità tecnica e eseguire le decisioni di realizzazione del servizio.

È possibile utilizzare diversi meccanismi per accedere ai pacchetti ISV. Durante questa fase, ogni pacchetto nell'ambito è analizzato per determinare e descrivere quali meccanismi sono disponibili per ogni pacchetto. In generale, i pacchetti ISV supportano uno o più dei seguenti meccanismi:

Meccanismo Descrizione
Esposizione diretta come servizio Il pacchetto espone direttamente la funzionalità utilizzando i servizi compatibili a SOA che sono tipicamente i servizi Web. Questi servizi possono essere elencati in un catalogo. L'implementazione specifica viene valutata per la conformità agli standard e all'interoperabilità.
Utilizzo delle API Il pacchetto fornisce una o più API che possono essere utilizzate per esporre i servizi nel pacchetto. Queste API possono essere utilizzate per esporre la funzionalità come un servizio, o i wrapper dei servizi Web o una facciata potrebbe essere sviluppata per consentire l'accesso alla funzionalità tramite l'API.
Direzione dell'accesso dati Nel caso in cui non sia disponibile nessuna API, ma si richiesto un servizio che espone i dati gestiti dal pacchetto ISV, viene sviluppato un servizio che accede direttamente al database utilizzato dal pacchetto.
Nota: Mentre questo approccio potrebbe essere tecnicamente fattibile, ignorando la logica del business nel pacchetto ISV si introduce un possibile rischio di corruzione dei dati o violazione dell'integrità dei dati rinforzati del programma. Per questo motivo, si consiglia che questa tecnica venga limitata ai servizi che eseguono operazioni in "sola lettura". Anche in questo caso, questo approccio è ancora a rischio a causa delle possibili modifiche agli schemi di dati ISV e dovrebbe quindi essere utilizzato con molta attenzione.

Tecniche di identificazione del servizio del pacchetto ISV

Durante questa fase, sono utilizzate diverse tecniche per analizzare i pacchetti ISV ed identificare la funzionalità che può essere potenzialmente esposta come un servizio. Le regole di business associate alla funzionalità sono anche identificate. Ogni tecnica viene utilizzata per valutare i pacchetti da una prospettiva diversa, consentendo ai pacchetti di essere analizzati a fondo per i servizi candidati. I risultati dell'analisi sono riportati nei prodotti di lavoro della Matrice funzione/sistema business e del Catalogo delle regole di business. Così come con le altre attività di identificazione SOMA, i servizi candidati vengono aggiunti al Portafoglio del servizio e alla Gerarchia del servizio.

  1. Revisione catalogo del pacchetto ISV dei servizi predefiniti

    Alcuni pacchetti ISV offrono un catalogo di servizi predefiniti. In tal caso, i servizi candidati per i domini nell'ambito e i componenti di business sono identificati tramite il catalogo e aggiunti al portafoglio dei servizi. Se supportata da ISV, questa tecnica rappresenta il modo più facile di identificare i servizi candidati utilizzando i pacchetti ISV.

    Nota: Durante la fase di specifica SOMA, il grado di granularità di questi servizi verrà considerato come parte delle decisioni di esposizione del servizi. Dunque è importante riportare il grado di granularità come una caratteristica dei servizi candidati durante l'identificazione SOMA. Potrebbe essere necessario aggregare o decomporre i servizi esposti in base al grado in cui si allineano con i servizi realizzati nei pacchetti ISV. Questa analisi aiuta ad allineare i servizi candidati nella gerarchia del servizio.
  2. Revisione delle API del pacchetto ISV

    I pacchetti ISV possono offrire una o più API che possono essere utilizzate per accedere alla funzionalità nei pacchetti. Queste API vengono esaminate per i domini nell'ambito ed i componenti business per identificare i servizi candidati da aggiungere al portafoglio del servizio. Poiché la funzionalità accessibile tramite queste API non sarà nativamente offerta come un servizio, un wrapper del servizio o la facciata dovrà essere sviluppata per esporre queste chiamate API come servizi. La flessibilità di questo approccio consente la combinazione di due o più chiamate API in un servizio singolo che può abilitare i servizi nei pacchetti da sviluppare per l'allineamento dei servizi nella gerarchia dei servizi. In questo caso, il professionista identifica i servizi nella gerarchia del servizio e li associa alla funzionalità di supporto e alle chiamate API nei pacchetti.
  3. Revisione associazioni processo di business ISV e flusso di lavoro

    I processi e i flussi di lavoro di business abilitati dai pacchetti ISV possono essere documentati in una copia cartacea o in formato elettronico. Queste risorse sono esaminate per identificare altri servizi candidati da aggiungere al portafoglio del servizio. In modo specifico, questa revisione dovrebbe eseguire una vista end-to-end dei processi di business nei pacchetti e nel contesto del flusso di lavoro nel quale il processo viene eseguito. Questo consente ai servizi candidati relativi di essere identificati e identifica anche il processo di business e le considerazioni del flusso di lavoro che vanno considerate durante la realizzazione del servizio.
  4. Identificazione dei limiti del servizio del pacchetto  

    Un pacchetto ISV viene sviluppato per supportare i processi di business e gestire i dati con un ambito che è allineato con i componenti di business (Aree funzionali) e i domini. Questi componenti di business formano l'"impronta" o "il limite del servizio" per i pacchetti ISV. Tuttavia, in un'azienda specifica, il pacchetto ISV può essere implementato in un sottoinsieme del limite del servizio totale per quel pacchetto. Identificando il limite del servizio totale per il pacchetto ISV, il professionista determina se bisogna aggiungere altri servizi nel limite del servizio del pacchetto al portafoglio del servizio. Soprattutto i professionista può determinare se nuovi servizi che sono obbligatori devono essere realizzati tramite i pacchetti ISV

    Se si determina che nuovi servizi sono richiesti per abilitare la soluzione orientata al servizio, il professionista dovrebbe determinare se questi si trovano all'interno del limite del servizio per il pacchetto ISV. In questo caso, i servizi nel pacchetto ISV che supportano la funzionalità richiesta sono identificati e aggiunti al portafoglio del servizio. Questo consente alla soluzione di utilizzare tutte le funzioni del pacchetto ISV e riduce il rischio di sviluppare la duplicazione nei sistemi multipli che supportano lo stesso componente di business.
  5. Analisi degli elementi di dati controllati nei pacchetti ISV

    Gli elementi di dati nell'ambito della soluzione sono valutati per determinare se sono gestiti nei pacchetti ISV. Se i dati vengono gestiti nei pacchetti ISV, altri processi di business nei pacchetti che leggono o aggiornano gli stessi dati sono analizzati per i servizi candidati da aggiungere al portafoglio del servizio.

    Questa analisi rivela anche i processi relativi o esterni e le interfacce che potrebbero essere influenzate dalla soluzione che deve essere considerata durante la realizzazione del servizio. Queste sono documentate e valutate durante la realizzazione del servizio.
  6. Analisi della sicurezza ISV e altri componenti tecnici

    Molti pacchetti ISV contengono i propri componenti di sicurezza per l'autenticazione e l'autorizzazione e potrebbero contenere altri componenti tecnici che supportano le funzioni come la registrazione e la messaggistica. Per ogni pacchetto, questi componenti sono identificati ed analizzati per identificare i servizi tecnici candidati che potrebbero essere aggiunti al portafoglio del servizio.

    Inoltre, durante l'analisi, qualsiasi problemi o vincolo che può essere introdotto da questi componenti viene identificato per la considerazione durante la realizzazione del servizio. Ad esempio, l'interazione richiesta con i componenti di sicurezza del pacchetto per accedere alla funzione nel pacchetto deve essere compresa e adattata durante la realizzazione del servizio.

L'applicazione di queste diverse tecniche consente ai servizi candidati nei pacchetti ISV dell'ambito di essere identificati da diverse prospettive. Questa identifica anche i problemi dei vincoli introdotti dai componenti funzionali e tecnici dei pacchetti ISV che devono essere considerati durante la realizzazione del servizio.

Verifica che tutti i requisiti non funzionali dell'asset siano documentati

Quando si documentano i requisiti non funzionali per gli asset esistenti è necessario considerare i seguenti argomenti chiave.

  • Gestione eccezione- È necessario comprendere come funziona la gestione dell'eccezione. Nell'elaborazione batch, quando si verifica l'eccezione, il programma si chiude (termina in modo anomalo) e produce un dump core. Al programmatore viene richiesto di controllare il dump core e di capire cosa fare. Questo potrebbe non essere accettabile. È necessario capire cosa fare, ad esempio, e come eseguire l'integrazione con il framework di gestione dell'eccezione.
  • Elaborazione e distribuzione dei dati - È necessario esaminare dove sono eseguiti i dati ed il processo. L'applicazione CICS è in esecuzione su una macchina e potrebbe inviare una richiesta ad un'altra macchina (conosciuta anche come funzione che passa a CICS) o chiamare in modo remoto i dati su un'altra macchina. Considerare la possibilità di andare direttamente (JDBC a DB) alla macchina remote dove è in esecuzione il processo o i dati, invece di utilizzare il connettore che va da JDBC a DB.
  • Disponibilità dati: Se viene personalizzato il file in VSAM che richiede, diciamo una finestra di manutenzione di 4 ore, allora non è possibile supportare un'assistenza clienti 24 ore al giorno 7 giorni su 7. È necessario considerare la possibilità di una nuova soluzione di memorizzazione.
  • Autorizzazione/Autenticazione: Molte applicazioni legacy hanno meccanismi di autorizzazione e autenticazione nel codice di applicazione. Questo richiede la migrazione dell'accesso utente ad un ambiente gestito associato supportato dalle migliori pratiche.
  • Ritardi di gestione temporanea - In genere i programmi di batch vengono eseguiti una volta al giorno durante la notte. Se i requisiti devono eseguire il programma più spesso, allora sarà necessario modificare il programma di pianificazione per modificare la frequenza.
Ulteriori informazioni