Sistemi Informativi aziendali

Sistemi informativi aziendali

Informazione

L'informazione è:

• Immateriale ma memorizzata su supporto digitale
• Continua
• Non si consuma con l'uso
• Tanta

Sistema informativo (SI)

Un SI è un sistema con dati in input trasformati e rilasciati come output in informazioni. Se ne misura

• Efficienza: buon uso delle risorse (input/output)
• Efficacia: fare le cose giuste

Modelli di riferimento di un SI

• Modello funzionale: descrive la funzionalità del sistema che offre attraverso la costruzione di rappresentazioni astratte. Es: BPM, diagrammi ER.
• Modello organizzativo: descrive SI operativi e direzionali (direzionali sono quelli necessari a prendere decisioni strategiche). Si deve automatizzare prima il processo operativo poi il direzionale. Relativamente a questo modello si fa riferimento alla Piramide di Anthony, più si sale verso l’alto più l’informazione è aperta ovvero occorre raccogliere dati dall’esterno. La piramide pone le Operations alla base (tipo commessi, magazzinieri, segreteria didattica delle uni), Manager (supervisione, analisi del livello operations, direttore del supermercato) e poi Executives (chi si occupa delle tattiche tipo al supermercato, consiglio di amministrazione). Tra il portafoglio direzionale e quello operativo c’è uno scambio degli obiettivi che vanno svolti a livello operativo che poi rimanda i risultati a quello direzionale. Nel controllo direzionale i dati sono una sintesi, pura informazione. A livello operativo della piramide il flusso di info è continuo, direzionale è periodico e strategico è non prefissato, ovvero la frequenza dipende dalla necessità.
• Modello informatico: si divide in tecnologico, atto a descrivere tecnologie, e applicativo, tipo gli ERP o altre applicazioni che regolano il sistema. Si parla di portafoglio applicativo come dell’insieme di app che mi aspetto siano presenti in un SI per soddisfare i requisiti dell’organizzazione.

Evoluzione ed architetture dei sistemi informativi

Nel tempo c’è stata un’evoluzione dei SI e la vediamo nell’immagine sottostante (modi di fare applicazioni software). L’OS è necessario affinché il calcolatore funzioni e deve gestire info, CPU, memoria, RAM, e accesso alle periferiche. Nei sistemi informativi abbiamo sia un lato Dati che un’app. Nel tempo i dati crescono mentre le applicazioni variano e si evolvono mantenendo però un CORE originario come base dello sviluppo. Questo perché il SI era monolitico→quindi a posteriore è difficile dividere le cose SISTEMI LEGACY.

I SI possono essere distribuiti: le fasi sono di Presentazione, Logica applicativa e Gestione dati e queste tre possono dividersi differentemente tra il lato Client e quello Server. Whatsapp è del tipo logica dati e applicativa distribuiti perché una porzione dei dati è sul cliente (video, audio…) e una sul server così come anche l’app è un po’ sul lato client tipo ridimensionamento file e sul lato server che si ha lo studio contatti, ricerca.

Se ho un modello THIN CLIENT significa che ho tutta logica di presentazione dal lato client mentre il resto è tutto server, si parla invece di situazioni con grafica molto sviluppata nel caso di FAT CLIENT ovvero tutte le fasi presenti sul lato client che condivide con il server solo la gestione dei dati (un esempio sono i giochi sul telefono dove la gestione dati sul server serve per consentire ad esempio di parlare con altri utenti online).

Topologie di rete

• Topologia a bus: un’info alla volta, la frequenza dei dati non può essere troppo elevata.
• Topologia ad anello
• Topologia a stella: tipica di reti cablate, l’info passa sempre per il centro della stella tipo per il router di casa.

IT e il suo ruolo nel tempo

Come l’IT è cambiato nel tempo? L’IT sono le componenti tecnologiche. Un tempo era una commodity ovvero considerata come un bene da avere di base, dunque era considerata un costo e una variabile dipendente, ma se è in grado di dare vantaggio competitivo alle aziende vuol dire che è di più. Negli ultimi 10 anni gli viene dato più valore grazie alle innovazioni tecnologiche, c’è stato quindi un inflection point basti pensare ad aziende che basano i loro profitti sull’IT come Uber o AIRBNB. L’epoca ora è quella dell’Internet of Things e l’IT diventa un’opportunità.

Architetture dei sistemi informativi

Nel tempo c’è stata un’evoluzione dell’architettura dei SI:

• Batch systems: facevano solo calcoli, non in t reale (tipo codice morse, codificabili a priori).
• Real-time systems: anni ’70, in t reale e sistemi come prenotazione biglietto aereo, sistemi bancari.
• Distributed informatics: anni ’80, facendo server sempre più piccoli fino ai singoli personal computer.
• Web systems: si aveva una rete per ogni organizzazione, si usava un sistema legacy – vecchio core- ma con una grafica migliorata.
• Service oriented architectures and cloud computing: Netflix è un esempio di cosa significa accesso al cloud.

Evoluzione della struttura organizzativa e ICT

Anche la struttura dell’organizzazione si è evoluta nel tempo in relazione all’ICT:

• Negli anni ’70 la struttura era GERARCHIA FUNZIONALE ed era tipica dei sistemi batch: non serve grande interattività perché con questa gerarchia gli ordini vanno solo dall’alto verso il basso.
• Anni ’80 si ha DIAMOND-SHAPED ORGANIZATIONS e il focus era sulle funzioni (ci sono anche knowledge workers) quindi ci sta una parte direzionale, una della conoscenza e una operaia.
• Attualmente ci sta la NETWORK ORGANIZATIONS e i rapporti sono anche tra organizzazioni stesse, focus sul processo.

Leggi di Grosch e di Parkinson

C’è stata anche un’evoluzione delle architetture che in origine era basata sulla centralizzazione sostenuto dalla Legge di Grosch: le performance di un computer aumentano con il quadrato del costo (se pc A costa il doppio di B allora è 4 volte più veloce). Dunque, siccome i pc più veloci sono i più convenienti dal punto di vista delle elaborazioni e dato che la velocità cresce con il quadrato del costo conveniva avere un unico pc e aggiornarlo. Centralizzare per sfruttare economie di scala dell’hardware.

CONTRO: L’elaboratore centrale è un collo di bottiglia e la legge di Grosch è valida solo fino ad un certo limite di concentrazione delle funzioni di un sistema.

Negli anni ’70 i limiti della legge di Grosch vengono messi alla luce dalla legge di Parkinson che introduceva un livello di capacità critico oltre il quale non si manifestavano più economie di scala e non conveniva più centralizzare. La legge di Grosch diventa così: è più conveniente prendere computer della potenza richiesta dalla funzione che deve svolgere. Nascono allora i sistemi client-server ove i pc condividono il carico computazionale con i mainframe.

Dal 1983:

• Le applicazioni sono cooperanti e si trovano su più nodi (elaborazione distribuita).
• La base di dati anche è distribuita perché accessibile da più nodi.

Si hanno allora livelli Logici (layer) che sono strati software nei quali viene partizionata un’applicazione e livelli Fisici (tier) che sarebbero livelli hardware su cui sono installati i software.

• Paradigma client/server: sono presenti due parti logiche una è il server che offre 1 o più servizi e poi si hanno un numero non precisato di componenti chiamati client che richiedono servizi al server.
• Sviluppo a 3 livelli (PAD, Presentazione, Applicazione, Dati).

TIER: un elaboratore (o cluster di elaboratori) su cui vengono allocati layer software e per migliorare la scalabilità, ovvero la capacità di soddisfare richieste crescenti con aggiornamenti adeguati in un grafico potenza(x), carico (y), servirebbe aumentare il numero di tier ossia avere un’architettura distribuita con più server in parallelo posso soddisfare più richieste.

Nel caso 3-tier di solito i 3 software sono assegnati a tier fisici che sono tipicamente: stazione di lavoro utente-pc-, un server intermedio e un server che gestisce dati. Caso 4-tier viene introdotto in più un server che funziona da gateway che smista i dati alle sorgenti dati richieste e si usa o in caso di TANTE sorgenti dati o se si hanno richieste molto frequenti.

Proprietà delle architetture

• Affidabilità: legata alla probabilità che il sistema sia operativo, MTTF, MTTR e Aff= MTTF/(MTTF+MTTR).
• Scalabilità: se un sistema non è scalabile si dice degradabile ovvero non è in grado di rispondere ad un’alta variabilità. Se la curva nel tempo degli eventi è lineare allora il sistema è scalabile.
• Tolleranza ai guasti: implica disponibilità e sostituibilità, serve il tempo per cambiare ovvero il tempo per sostituire la macchina di calcolo è basso.

Sistemi informativi aziendali

In uno scenario aziendale disponiamo di database (informazioni dirette, dati), sistemi gestionali (si prendono a scatola chiusa) e sistemi legacy (con core antichi ma si risistema il lato grafico).

Caso particolare di sistema informativo: applicazioni web

Web information system

Si sente l’esigenza di separare la presentazione da logica applicativa e dati. Presentazione: non solo tramite il browser per visualizzare la pagina (tipo i chrome-book che sono dei computer in cui non c’è nulla al di fuori del browser). La presentazione si sviluppa su tre attività principalmente di visualizzazione della pagina (browser), risposta alla richiesta http (web server) e generazione pagina (script engine) e può essere svolta su più livelli fisici.

Infostud è un esempio di WIS. L’applicazione è un browser dedicato in questo caso alla Sapienza.

Quali sono i criteri di progetto per scegliere che tipo di applicazione voglio?

• Capacità di rete
• Potenza di calcolo che mi serve
• Potenza di calcolo che impongo come vincolo ai miei client

Ad esempio, più ho delle reti veloci più posso fare browser (che quindi è lato cliente) ma se la capacità di rete è bassa mi conviene mettere anche la logica applicativa sul client.

Esempi di logica applicativa sul client sono il gaming online perché il browser da solo non è ancora abbastanza potente.

Architetture Internet

• Configurazione DUAL host

  Si tratta di un sistema distribuito in cui, nel modello ideale, il componente intermedio contiene tutta la logica dell’applicazione (altrimenti è un po’ sul front-end un po’ sul back-end) e ha come vantaggi la scalabilità e la flessibilità. Si introduce il FIREWALL come prima barriera tra il client/browser e l’internet privata (Host 1) che potrebbe essere il router di casa. Successivamente per garantire la sicurezza tra Host 1 e Host 2 si mette un altro firewall e l’area tra i due host prende il nome di DMZ (Demilitarized zone). Il primo firewall (tra client e host 1) dice qual è la macchina cui ci si può connettere e filtra quindi a livello di indirizzo IP; il secondo tra host 1 e host 2 legge anche il messaggio e filtra a livello di contenuto dei messaggi. Si usano due firewall per motivi di efficienza. In questo modo il numero di clienti che manda richieste all’host 2 sarà inferiore rispetto a quello che arriva all’host 1. Nei casi di configurazione multi-tier le richieste del client sono servite da diversi livelli del server.

• Server Farm

  Esempi di Server Farm possono essere i servizi streaming. Una server farm è un insieme di elaboratori sullo stesso livello del paradigma client/server che condividono il carico elaborativo, le applicazioni e talvolta i dati. Ad alti livelli viene gestita come unica risorsa. In questo modo le macchine possono essere progettate con minori capacità e potenze e abbassa anche i costi di gestione dato che con i moderni software è possibile amministrare simultaneamente e remotamente i server della farm.

  Tipologie applicative della server farm:

  • Cloning: Su ogni nodo vengono installate le stesse applicazioni software e gli stessi dati. Le richieste poi vengono instradate ai vari nodi usando un sistema di load-balancing. Un insieme di cloni dedicati allo svolgimento di un particolare servizio è detto RACS (Reliable Array of Cloned Services).
    • In questo modo si hanno vantaggi sulla scalabilità e sulla tolleranza ai guasti e disponibilità del servizio: infatti se un nodo è guasto un altro può prenderne il ruolo e o con minori prestazioni a causa della mole di lavoro oppure se il meccanismo di rilevazione del malfunzionamento del nodo o dell’applicazione sono integrati nel sistema di load-balancing l’utente nemmeno si accorge del problema.
  • I RACS possono avere due configurazioni:
    • Shared-nothing: i dati memorizzati sono uguali e risiedono in un disco fisso per ogni clone e quindi ogni aggiornamento va ripetuto su ogni clone separatamente. Risulta la scelta migliore in caso di applicazioni di sola lettura “read-only” mentre ovviamente aumentano le complicazioni nei casi “write-intensive”.
    • Shared-disk: si parla di cluster e si intende quando i cloni condividono un server di memorizzazione che gestisce i dischi fissi. Tuttavia richiede un ulteriore intervento di fault tolerance in termini di disponibilità sul server di memorizzazione.
  • Partitioning: Si distribuisce sia la logica applicativa che i dati creando dei server dedicati ad esempio il sistema vendite di un’azienda viene suddiviso per tipologie di clienti o per linee di prodotto ed ognuna è gestita da un nodo. Il sistema è completamente trasparente alle applicazioni e le richieste vengono inviate alla partizione che riesce a gestire la richiesta. Tuttavia, non migliora la disponibilità perché i dati restano memorizzati su un solo server e in caso di guasto la parte di servizio richiesta non può essere implementata. Spesso, infatti, si unisce a tale tecnica quella della clonazione dei singoli server su ogni partizione e si creano così dei pack. Si parla allora di RAPS (Reliable Array of Partitioned Service) che garantisce sia scalabilità che disponibilità del servizio.

Gestione dei sistemi informativi

CHI GESTISCE I SISTEMI INFORMATIVI (chi ne fa manutenzione, sviluppo…)?

Modalità di gestione di un SI:

• In house: i servizi sono gestiti internamente ad un’unità dell’organizzazione e solitamente si sceglie quando voglio avere in mano la situazione perché il SI è il mio vantaggio competitivo (tipo Amazon).
  • Pro: controllo totale sul SI e la qualità dovrebbe essere superiore
  • Contro: costi elevati
• Servizi condivisi (insourcing): una compagnia fornisce servizi IT a tutte le unità, ovviamente saranno SI abbastanza standardizzati.
• Supporto esterno: I servizi sono gestiti internamente ma con il supporto di compagnie specializzate o società di consulenza.
• Consorzio: Un gruppo di compagnie con bisogni simili crea un consorzio specializzato per alcuni servizi (tipo call center o data center).
• Outsourcing selettivo: Alcuni servizi, solitamente non core, sono gestiti da aziende esterne (tipo la Sapienza, alcuni aspetti del SI vengono affidati ad altri enti -tipo email sapienza gestita da google-).
• Outsourcing completo: Tutto l’IT è gestito esternamente. Se l’infrastruttura appartiene al cliente il servizio è chiamato facility management. L’organizzazione compra una commodity quindi le opzioni e funzioni sono fisse ma i costi sono molto più bassi.

Come gestire l’outsourcing?

• Definendo chiaramente i SLA livelli di servizio e la sua gestione descrivendo il servizio, monitoraggio, documentazione, reporting
• KPI per il processo/servizio esternalizzato.

Architetture avanzate

La SOA (Service Oriented Architecture) è un paradigma architetturale per progettare sistemi software. Parliamo di architetture a servizio ovvero il Software diventa una componente della fornitura di servizi (giocano un ruolo nelle interazioni Business to Business, B2B).

Ovvero per sviluppare Sistemi Informativi si fa riferimento a ciò che il sistema deve offrire così che i moduli software possono essere utilizzati ad altri software. Ad esempio l’app meteo sul telefono è collegata ad un data center di un sito meteo, ma l’accesso a tale sito ce l’hanno anche le tv ad esempio o altri dispositivi perché la fornitura di informazioni è essa stessa un servizio.

Il SI è costruito anche con un modulo software che dà solo informazioni così che tale modulo possa essere accessibile anche ad altri. Questo ha consentito la nascita delle applicazioni che sono servizi che prendono le informazioni da moduli software invocabili su internet dai creatori.

Architetture orientate ai servizi

Gli elementi di tali architetture sono:

• Service requestor: chi richiede l’esecuzione del servizio
• Service provider: entità che fornisce il servizio
• Service registry: permette di pubblicare e cercare i servizi (il provider ci pubblica la sua capacità e lì lo user cerca)