Architettura telematica

Da Wikipedia, l'enciclopedia libera.
Vai alla navigazione Vai alla ricerca

L'architettura telematica è il progetto esecutivo che descrive l'intera struttura delle informazioni e dei componenti ed apparati informatici e di comunicazione che le gestiscono[1].

Definire l'architettura telematica di una realtà significa realizzare un documento progettuale che raggruppi e renda uniformi le descrizioni delle architetture hardware e software con le analisi e le soluzioni operative e con le regole e le strategie di gestione delle informazioni e delle comunicazioni.[2][3][4][5][6][7][8] Tale progetto è finalizzato ad ottenere i risultati stabiliti attraverso il coordinamento strategico di procedure e documenti altrimenti indipendenti[9].

Storia[modifica | modifica wikitesto]

Lo studio dei sistemi telematici è iniziato come il sotto-ramo dell'informatica che si prefiggeva lo scopo di comprendere e razionalizzare l'amministrazione ICT nelle aziende per portare a compimento l'informatizzazione del sistema informativo aziendale. Con la convergenza di informatica e telefonia nel più ampio sistema telematico, la materia si è evoluta trasformandosi in un campo di studio superiore all'interno delle maggiori facoltà di amministrazione e gestione d'impresa del mondo.

Avviato dall'analisi delle formulazioni del piano regolatore per il CED (detto IT Masterplan), lo studio delle metodologie di rappresentazione è entrato di diritto nei corsi di studio indirizzati alla formazione del personale dirigente, rendendo fondamentale l'individuazione del CIO per assistere il consiglio direttivo su questi argomenti.

Lo scopo che si vuole raggiungere con gli studi più recenti è il perfezionamento delle tecniche di progettazione per migliorare il controllo, la pianificazione e la gestione delle attività e l'aumento di velocità nell'elaborazione dei dati, delle informazioni e delle comunicazioni.

Ciclo di vita[modifica | modifica wikitesto]

La realizzazione dell'architettura telematica si sta diffondendo rapidamente in Italia e sta seguendo queste fasi:

  • Individuazione dell'esigenza: l'azienda sente la necessità di comprendere appieno la propria struttura tecnica per perseguire gli obiettivi istituzionali;
  • Studio di fattibilità: il consulente si occupa di definire, in accordo con l'azienda, le alternative possibili ed effettua una prima analisi volta a impostare una proposta di cammino critico per la realizzazione delle varie componenti dell'architettura.
  • Analisi dei requisiti: consiste nel verificare se le premesse emerse durante lo studio di fattibilità sono suffragate dai dati. Questa fase richiede un'interazione con gli utenti
  • Analisi di contesto: ha lo scopo di comprendere la situazione attuale e raccogliere la documentazione esistente.
  • Progettazione: in questa fase si esegue l'analisi funzionale ed il progetto architetturale e si definiscono i processi aziendali sottesi alla vita quotidiana in azienda.
  • Sviluppo della documentazione: consiste nella realizzazione dei documenti di gestione secondo la struttura e le caratteristiche definite nella fase di progettazione; ci si occupa inoltre di sviluppare le strategie di governo dell'ICT prevedendo, per quanto possibile, tutte le condizioni operative.
  • Validazione: è il momento in cui si redige la lista delle componenti da acquisire per portare a regime l'architettura. Durante questo passo si verifica la situazione amministrativa.
  • Formazione: si erogano i corsi di formazione e si attivano le varie componenti mentre si istruisce il personale sulle modalità di utilizzo.
  • Produzione: in questa fase l'architettura telematica diventa operativa. Se non si verificano malfunzionamenti o revisioni delle funzionalità, questa attività richiede solo operazioni di gestione e manutenzione.
  • Manutenzione: con la manutenzione correttiva si consolida il sistema, mentre con la manutenzione evolutiva lo si completa ed arricchisce di funzionalità inizialmente non individuate.

Il suddetto ciclo di vita ha origine dalla formalizzazione dei sistemi informativi, differenziandosi secondo le necessità relative alle architetture di comunicazione ed alle esigenze di studio dei processi aziendali; è bene ricordare che tale cammino va adattato alle situazioni esistenti e può capitare che durante l'esecuzione di un'attività si debbano rivedere decisioni o documenti precedenti.

Componenti[modifica | modifica wikitesto]

L'architettura telematica è composta dall'insieme dei sistemi informativi, tecnologici e comunicativi dell'azienda e riporta le indicazioni inerenti alla gestione, la manutenzione, la sicurezza, il Problem solving, il Disaster recovery e le informazioni amministrative necessarie a una corretta gestione[10].

Analisi dei requisiti[modifica | modifica wikitesto]

  • Elenco degli scopi da raggiungere
  • Verifica del quadro generale emerso durante le riunioni introduttive

Analisi di contesto[modifica | modifica wikitesto]

  • Fotografia della situazione in essere

Analisi funzionale[modifica | modifica wikitesto]

  • Descrizione dei flussi di lavoro interni all'IT
  • Rappresentazione del sistema di condivisione delle informazioni interne all'IT
  • Formalizzazione della scala gerarchica e dei compiti individuali
  • Analisi di processo
    • Rappresentazione dei processi di gestione ordinaria e straordinaria da parte del personale IT
    • Rappresentazione dei processi di funzionamento dell'architettura informatica
    • Rappresentazione del ciclo di vita delle informazioni

Progetto architetturale[modifica | modifica wikitesto]

Documentazione di gestione[modifica | modifica wikitesto]

  • Politica di assegnazione e rimozione del nome utente
  • Linee guida per l'utilizzo delle password e dei token
  • Schema delle metodologie di backup
    • Piano di protezione dal sabotaggio interno ed esterno
  • Regolamento di sicurezza
  • Regolamenti per l'aggiornamento hardware e software
    • Procedura di dismissione e smantellamento del materiale obsoleto
  • Formalizzazione delle liste di controllo per le operazioni ordinarie e straordinarie
    • Piano di formazione del personale
  • Regole per la gestione documentale

Governo dell'ICT[modifica | modifica wikitesto]

Analisi fabbisogno di adeguamento[modifica | modifica wikitesto]

  • Descrizione degli eventuali componenti da aggiungere all'architettura di contesto per raggiungere la soluzione tecnologica
  • Eventuale Preventivo di spesa per l'adeguamento dell'architettura

Situazione Amministrativa[modifica | modifica wikitesto]

  • Contratti di fornitura e di manutenzione.
  • Quadratura delle licenze software

Metodologie di progettazione, sviluppo e descrizione[modifica | modifica wikitesto]

Nel tempo si sono sviluppati diversi metodi per rappresentare tutto ciò che ruota intorno al CED e, più in generale ed in tempi recenti, al reparto ICT.

Rappresentazione a blocchi correlati[modifica | modifica wikitesto]

La prima metodologia di rappresentazione delle architetture telematiche risale agli anni 70, nata dalla necessità di fare distinzione tra informatica concentrata e informatica distribuita[11]. Inizialmente gli utenti remoti si collegavano ad un unico calcolatore centralizzato (es. mainframe) in cui risiedeva tutta la potenza elaborativa; con l'avvento del Personal Computer, ci si interrogò sulla possibilità di realizzare reti complesse di più calcolatori collegati tra loro in uno schema a maglia così che le informazioni potessero viaggiare dalla sorgente alla destinazione seguendo percorsi distinti. Sebbene i primi progetti furono sviluppati a scopo militare negli USA, oggi ne abbiamo applicazioni civili in molteplici ambienti, il più noto dei quali è rappresentato da Internet[12].

È una metodologia che ha come scopo unico la descrizione dei collegamenti fisici e logici degli apparati che identificano i nodi e fa distinzione tra i diversi tipi di collegamento: linee telegrafiche, telefoniche, commutate o dedicate, ponti radio, satelliti per le telecomunicazioni, ecc.[13]

È una tecnica che venne abbandonata quando ci si rese conto che l'architettura telematica doveva astrarsi ad un livello superiore rispetto alle connessioni fisiche per poter descrivere correttamente la crescente complessità dei sistemi. Rimane tuttora valida come tecnica di rappresentazione degli impianti fisici (livello 1, 2 e 3 della pila ISO/OSI).

Rappresentazione a lista[modifica | modifica wikitesto]

La storica metodologia di descrizione della situazione tecnica è strutturata come una lista di apparecchiature e una lista di correlazioni; le due liste sono tra loro legate a doppio filo attraverso le specifiche di progetto oppure secondo le regole di utilizzo.

È una metodologia che ha come scopo principale l'inventario del materiale presente ed il controllo approfondito delle risorse impiegate, sia tecniche che economiche; produce una documentazione molto dettagliata ed orientata all'ottimizzazione della spesa e del TCO.

È una tecnica nata prima della convergenza voce-dati e non permette di gestire contemporaneamente i due servizi; l'infrastruttura informatica deve perciò essere descritta in maniera separata dall'infrastruttura telefonica e l'unione delle due descrizioni fornisce un quadro telematico completo.

Rappresentazione ad oggetti[modifica | modifica wikitesto]

La più accreditata metodologia di rappresentazione dell'Architettura Telematica si basa sul concetto di oggetto e prende quindi il nome di Architettura Telematica ad Oggetti (ATO).
È una metodologia di rappresentazione che integra la realtà ICT nella struttura aziendale poiché si basa sui dati esistenti e sulla situazione attuale e la ottimizza gradualmente: costruisce la documentazione in maniera che ogni classe di oggetti sia autoreferenziale e contenga sia le informazioni che le procedure che operano su tali informazioni, siano esse strutturate o meno.

L'obiettivo principale della sua implementazione in azienda è di migliorare i percorsi delle informazioni tra le classi e le relazioni tra gli oggetti secondo step predefiniti e concordati in anticipo[14]. Permette inoltre la valutazione ed il confronto di molteplici scenari per ciascuna risorsa, agevolando la redazione dei piani necessari ad ogni unità funzionale, sia tecnica che amministrativa.

È una tecnica relativamente nuova, fornita di scarsa documentazione, che obbliga ad un apprendimento sul campo da chi già ne fa uso ma permette di fare modifiche anche radicali senza perdere il contatto con la realtà aziendale, produce tutta la documentazione necessaria ad un migliore sfruttamento delle risorse e garantisce risposte rapide ed integrate nei processi di business.

Il tuning[modifica | modifica wikitesto]

Eseguire il tuning significa ottimizzare l'architettura precedentemente formalizzata secondo i parametri di utilizzo quotidiano.

I passi principali da compiere dopo aver messo in produzione l'architettura sono la verifica di rispondenza ai bisogni, la risoluzione dei problemi evidenziati e l'adeguamento della documentazione per queste quattro classi di criticità:

  1. Necessità quotidiane di primo impatto
  2. Rispondenza ai bisogni a breve termine
  3. Analisi dell'impatto a medio periodo
  4. Segnalazione di note di ampio respiro

Normativa italiana[modifica | modifica wikitesto]

Note[modifica | modifica wikitesto]

  1. ^ Jessup, Leonard M.; Joseph S. Valacich (2008). Information Systems Today (3rd ed.). Pearson Publishing. Glossary p. 416
  2. ^ Timothy Davis, Robert Geist, Sarah Matzko e James Westall, τ´εχνη: A First Step, in Technical Symposium on Computer Science Education, marzo 2004, pp. 125–129, ISBN 1-58113-798-2.
    «In 1999, Clemson University established a (graduate) degree program that bridges the arts and the sciences... All students in the program are required to complete graduate level work in both the arts and computer science»
  3. ^ Ken Hoganson, Alternative curriculum models for integrating computer science and information systems analysis, recommendations, pitfalls, opportunities, accreditations, and trends, in Journal of Computing Sciences in Colleges, vol. 17, n. 2, dicembre 2001, pp. 313–325, ISSN 1937-4771 (WC · ACNP).
    «The field of information systems as a separate discipline is relatively new and is undergoing continuous change as technology evolves and the field matures»
  4. ^ Peter Denning, Ubiquity a new interview with Peter Denning on the great principles of computing, vol. 2007, June, giugno 2007, pp. 1–1.
    «People from other fields are saying they have discovered information processes in their deepest structures and that collaboration with computing is essential to them.»
  5. ^ Pearson Custom Publishing & West Chester University, Custom Program for Computer Information Systems (CSC 110), (Pearson Custom Publishing, 2009) Glossary p. 694
  6. ^ Jennifer Polack, Planning a CIS Education Within a CS Framework, in Journal of Computing Sciences in Colleges, vol. 25, n. 2, dicembre 2009, pp. 100–106, ISSN 1937-4771 (WC · ACNP).
  7. ^ CSTA Committee, Allen Tucker, et alia, A Model Curriculum for K-12 Computer Science (Final Report), (Association for Computing Machinery, Inc., 2006) Abstraction & p. 2
  8. ^ Peter Freeman e David Hart, A Science of Design for Software-Intensive Systems Computer science and engineering needs an intellectually rigorous, analytical, teachable design process to ensure development of systems we all can live with., in Communications of the ACM, vol. 47, n. 8, agosto 2004, pp. 19–21, ISSN 0001-0782 (WC · ACNP).
    «Though the other components' connections to the software and their role in the overall design of the system are critical, the core consideration for a software-intensive system is the software itself, and other approaches to systematizing design have yet to solve the "software problem"—which won't be solved until software design is understood scientifically»
  9. ^ Sue Kelly, Nicola Gibson, Christopher Holland e Ben Light, Focus Issue on Legacy Information Systems and Business Process Engineering: a Business Perspective of Legacy Information Systems, in Communications of the AIS, vol. 2, n. 7, luglio 1999, pp. 1–27.
  10. ^ Shrader, C. B., L. Taylor, and D. R. Dalton (1984), “Strategic planning and organizational performance: A critical appraisal,” Journal of Management, 10, 149-171.
  11. ^ Michele Naso, ATLAS, Architetture hardware e sistemi informatici, 2007, ISBN 88-268-1014-1.
  12. ^ Douglas E. Comer, The Internet Book, 2001, ISBN 0-13-030852-8.
  13. ^ Andrew S. Tanenbaum, Reti di calcolatori, 2000.
  14. ^ D. J. Power, A Brief History of Decision Support Systems, su dssresources.com. URL consultato il 1º novembre 2010.

Voci correlate[modifica | modifica wikitesto]

Estratto da "https://it.wikipedia.org/w/index.php?title=Architettura_telematica&oldid=138982117"