Appunti Sistemi informativi

Modello di architettura funzionale

A differenza del modello organizzativo, dove rappresentiamo le funzionalità del sistema, nel modello di architettura funzionale rappresentiamo i componenti concettuali di un Sistema.

6.1 Livelli di Aggregazione e Astrazione

Si possono descrivere le architetture dei SI a diversi livelli che si differenziano per il livello di aggregazione e per la natura stessa dei livelli. Il Livello di Astrazione definisce anche il dominio di utilizzo di quell'architettura, infatti possiamo distinguere tra Architetture:

• Istanza: Architettura di uno specifico SI in uno specifico contesto.
• Standard: Architettura definita come Standard per una classe di SI in uno specifico contesto.
• Riferimento: Architettura definita come uno standard per una classe di sistemi per varie organizzazioni.

Nella prospettiva architetturale di BOAT, le architetture di riferimento devono essere indipendenti dalla tecnologia. Dividiamo le architetture dei SI in 3 livelli di aggregazione:

- Market-Level:

è specificato. Il Front-End (FE) rappresenta l'interfaccia utente attraverso cui gli utenti interagiscono con il sistema di E-Business. Il Front-End-System (FES) è il modulo software che gestisce le funzionalità del Front-End, come la presentazione dei dati e la gestione delle interazioni utente. Oltre al Front-End, l'architettura Market-Level comprende anche altri componenti software funzionali, come il Back-End (BE) e il Back-End-System (BES). Il Back-End gestisce le funzionalità di business del sistema di E-Business, come l'elaborazione degli ordini, la gestione degli inventari e la gestione dei pagamenti. Il Back-End-System è il modulo software che gestisce le funzionalità del Back-End. Le interfacce ad alto livello consentono la comunicazione e lo scambio di dati tra i diversi componenti software funzionali. Queste interfacce definiscono i messaggi scambiati tra le parti e le modalità di interazione. In sintesi, l'architettura Market-Level di un sistema di E-Business a livello inter-organizzativo definisce la struttura del sistema in termini di componenti software funzionali e interfacce ad alto livello. Questa struttura è determinata dalla topologia delle parti coinvolte nello scenario e dalle modalità di interazione tra di loro.

ènecessariamente uno ad uno e tutti i FES a questo livello vengono esplicitati. I sistemi di Back-End sono mostrati come Black Box perché non sono rilevanti a questo livello.

-Party-Level: descrive le strutture a livello di organizzazioni singole. Nell’E-Business si concentra sulle interfacce verso il mondo esterno (senza descriverlo) ed è quindi un’architettura intra-organizzativa.

“L’architettura Party-Level di un sistema di E-Business di un partecipante in uno scenario definisce la struttura di quel sistema a livello intra-organizzativo di quel partecipante in termini di:

1. componenti funzionali software che supportano funzioni specifiche di quel partecipante,
2. interfacce di alto livello che supportano le interazioni fra componenti e partecipanti dello scenario”

Questo livello di astrazione descrive in maniera precisa i Sistemi di Back-End e le interfacce con altri sistemi differenziando i componenti in Componenti Generici, Database e

supportano la comunicazione tra i componenti. Questo livello si concentra sulle specifiche tecniche e sulle implementazioni dei componenti software che costituiscono il sistema. - Componenti per la memorizzazione e accesso ai dati: questi componenti sono responsabili della gestione dei dati all'interno del sistema. Essi includono il database, i sistemi di gestione dei database (DBMS) e i connettori che consentono la comunicazione tra il sistema e il database. - Connettori: i connettori sono le interfacce che consentono la comunicazione tra il sistema front-end e il sistema back-end. Essi definiscono i tipi di messaggi che possono essere scambiati tra i due sistemi e regolano la comunicazione tra di essi. - Architettura Party-Level: questa è un'architettura che descrive la struttura di un'organizzazione coinvolta in vari scenari. Essa si sovrappone all'Enterprise Architecture (EA) condividendo alcune parti. Questo livello può essere considerato come un sottoinsieme di un'architettura funzionale complessiva, adattata a uno specifico scenario. - Architettura System-Level: questa è un'architettura che definisce la struttura di uno specifico partecipante in uno specifico scenario. Essa si concentra sui componenti software che supportano specifiche sotto-funzioni di un partecipante e sulle interfacce che supportano la comunicazione tra di essi. Questo livello si occupa delle specifiche tecniche e delle implementazioni dei componenti software che costituiscono il sistema.

supportano le interazioni tra quei componenti

L'architettura System-Level, quindi, è la specifica di una specifica struttura di un sistema di Front\Back -End, è poco interessante dal punto di vista generale dell'E-Business. Ovviamente le interfacce di questi sistemi devono essere congruenti con quelle specificate nell'architettura di livello superiore.

6.2 Relazioni tra architetture organizzative e funzionali

Le architetture Market-Level possono essere raffinate in architettura Party-Level, a loro volta raffinabili in architettura System-Level e allo stesso tempo l'aggregazione di strutture più dettagliate porta ad avere strutture più di alto livello. Nell'E-Business troviamo un forte allineamento tra i requisiti a livello Business (B) e SI descritti nella prospettiva di architettura (A) arrivando ad avere, nei sistemi più semplici, una relazione binaria tra modulo descrittivo ad alto livello nella sezione organizzativa e

tramite strumenti digitali

• CRM- Customer Relationship Management: Moduli a supporto delle relazioni con clienti, anche potenziali
• ERP- Enterprise Resource Planning: Suite software per il supporto alle attività operative dell'azienda
• APS- Advanced Planning and Scheduling: Suite per la gestione delle materie prime e capacità produttiva
• MES: Manufacturing Execution System: Sistemi usati per tracciare e documentare il processo produttivo

Durante la progettazione, a questo livello bisogna valutare l'approccio migliore per la realizzazione del sistema scegliendo tra le strategie di Make or Buy.

L'implementazione di queste applicazioni richiede l'utilizzo di diverse tecnologie infrastrutturali, gestite dal Livello Piattaforma, in grado di gestire l'accesso ai dati, la comunicazione tra applicativi e altri aspetti non funzionali. Possiamo dividere questo livello in 4 macroaree:

Tra tecnologie orientate alle funzionalità

troviamo:

• DBMS, Database Management System: sistemi per gestire e manipolare dati
• DPMS, Business Process Management System: sistemi per gestire e controllare attività di business
• UIS, User Interface System: insieme di servizi capaci di supportare l'interazione da parte degli utenti
• Rule Engine: Sistema Software in grado di testare le regole di business indipendentemente dalle applicazioni

Le Tecnologie orientate agli aspetti non funzionali includono invece tecnologie in grado di garantire alcune caratteristiche non funzionali legate alle applicazioni (come la sicurezza dei dati). Le Tecnologie di base invece comprendono tecnologie per gestire la comunicazione tra applicativi e componenti, utile per tenere traccia dei componenti e dei servizi in uso. Ultima categoria è quella delle Advanced Platform Technology, dedicate all'integrazione e comunicazioni tra applicazioni.

Le tecnologie a Livello di Architettura Fisica comprendono i paradigmi con

cui è possibile allocare le applicazioni sulle macchine fisiche, specificando eventuali soluzioni di outsourcing. Una tendenza recente è quella della virtualizzazione delle risorse, che rende più flessibile la gestione del sistema, distribuendo le risorse virtuali sulle risorse fisiche effettivamente disponibili in base alla necessità di calcolo. Un concetto importante è quello di Enterprise Service Bus (ESB), che fornisce un'infrastruttura di comunicazione tra servizi senza conoscerne realmente la collocazione fisica.

Aspetti Tecnologici

8. Tecnologie a Livello Applicativo

Il Sì è un sistema complesso composto da diverse applicazioni che sono nella maggior parte dei casi modulari: il modulo è definito come un componente software autonomo associato a una o più funzionalità. La modularità è una caratteristica fondamentale in quanto migliora la manutenibilità e abbatte i costi.

8.1. Gli ERP,

L'ERP (Enterprise Resource Planning) è una suite software che offre moduli di supporto del sistema operazionale e quindi delle transazioni interne all'organizzazione finalizzate alla gestione dell'impresa. Le caratteristiche principali sono:

• Unicità dell'informazione, non ci sono duplicati e sprechi di memoria
• Modularità: i moduli sono autonomi e autosufficienti, quindi più facili da gestire
• Prescrittività: Ogni modulo è codificato con le "Business Rules" del settore

I moduli possono essere classificati in 3 categorie: Istituzionali, Settoriali e Direzionali. I moduli istituzionali e direzionali sono intersettoriali (orizzontali) mentre i moduli settoriali sono specifici di un determinato settore (verticali) e servono per la gestione di singole produzioni. I moduli istituzionali servono a normale e regolarizzare il processo, i moduli direzionali forniscono

Elaborazioni di dati volte a dare una visione d'insieme delle attività svolte a livello operativo. L'adozione di un ERP all'interno di un'azienda si può rappresentare in un'architettura BOAT Party-Level, questo utilizza una base di dati unica e offre le proprie funzionalità tramite interfacce che permettono agli utenti di specificare le richieste.

Dal punto di vista architetturale si possono individuare 3 approcci di implementazione: il paradigma Client-Server, utilizzato agli albori e istallato su uno o più server a cui gli utenti accedevano. Con lo sviluppo del web abbiamo la nascita del Web-Based ERP: ERP basato su web-app e infine, si sta passando al Cloud Computing, dove i vendor offrono i propri servizi in modalità "SaaS: Software as a Service". L'ultimo metodo ha diffuso gli ERP esponenzialmente tagliando ulteriormente i costi della vendita e quindi di acquisto.

Non essendo software specifici, ma

progettati per un intero settore (COTS), una volta installati non sono immediatamente utilizzabili ma hanno bisogno di essere configurati per rispondere al meglio alle esigenze aziendali, questo passaggio è detto configurazione.