Un Caffè Sospeso da gustare, insieme a Gian Franco Stucchi, in un tour guidato tra i business object alla ricerca di qualche certezza in un mondo in perenne formazione
Non è mai esistito, nella breve ma tumultuosa storia delle tecnologie dell’informazione, un momento come quello attuale caratterizzato dalla concentrazione di una molteplicità di condizioni estremamente favorevoli per l’attuazione di un mutamento paradigmatico nello sviluppo del software applicativo.
Le metodologie, le architetture, gli indirizzi strategici, le visioni tecnologiche e gli approcci organizzativi stanno confluendo in un unico punto virtuale, nel quale si accumulano ed interagiscono creando fenomeni di risonanza e pervasività. La tecnologia degli oggetti (OT), le architetture distribuite, i database multidimensionali, i sistemi OLAP (On Line Analytical Processing) e la ripatizione delle applicazioni e dei dati sono solo alcuni degli indirizzi tecnici emergenti.
Le direzioni funzionali lungo le quali si articola lo sviluppo dei sistemi economici e sociali evidenziano una tendenza alla focalizzazione degli obiettivi strategici su pochi elementi chiave, all’appiattimento delle strutture, all’eliminazione delle barriere burocratiche, ed enfatizzano le comunicazioni tra varie entità, le attività svolte in collaborazione ed operanti secondo una logica globale di tipo pull (trainata dal mercato), sostitutiva della precedente di tipo push (spinta dall’interno).
Uno dei concetti più significativi, dal punto di vista dello sviluppo del software applicativo, è quello di business object (BO), particolarizzazione dell’idea di “oggetto” ed elemento costruttivo fondamentale delle nuove soluzioni applicative gestionali. Il vantaggio principale dei BO consiste nella riduzione del grado di difficoltà insito nella modellizzazione dei processi di business e nella possibilità di creazione di un alveo favorevole ad una transizione, uniforme e non traumatica, dal modello concettuale astratto dell’entità o del processo in esame alla sua implementazione fisica.
Il termine “oggetto” vaga da molto tempo nel mondo delle tecnologie dell’informazione ma solo recentemente è uscito dagli ambienti di nicchia, collocandosi nel cosiddetto mainstream tecnologico. Anch’esso, come il termine “sistema”, è inflazionato e logorato dall’uso improprio che spesso ne viene fatto dalla letteratura più o meno specialistica e dal marketing di talune case produttrici.
L’idea fondamentale dell’OT, dal punto di vista dello sviluppatore, consiste nella rappresentazione di un’entità reale con un oggetto, cioè con un unico modulo software – sicuro, robusto, compatto ed autoconsistente – che incapsula sia lo stato di un’entità (i dati) sia i suoi possibili comportamenti (i metodi). Non tutti gli oggetti hanno lo stesso scopo: per progettare le applicazioni gestionali, gli oggetti possono essere divisi in due categorie: gli application object ed i business object.
Un application object è un oggetto che realizza una generica infrastruttura di programmazione e viene utilizzato per costruire il substrato operativo di una soluzione applicativa. In questa classe rientrano, ad esempio, gli oggetti impiegati per la creazione delle interfacce grafiche, per l’esecuzione delle funzioni di ordinamento o di sequenzializzazione delle informazioni, per la realizzazione delle applicazioni query SQL, etc.
Un business object è la rappresentazione di un elemento di rilevanza aziendale e costituisce, come tale, una cristallizzazione di un frammento della conoscenza aziendale. Una working definition derivata da quelle proposte dal BOMSIG (Business Object Management Special Interest Group) dell’OMG (Object Management Group, un consorzio al quale appartengono diverse centinaia di imprese IT) è la seguente:
“Un BO è la rappresentazione di un’entità di business attiva ed è costituito, almeno, da un nome, da una definizione e da un insieme di attributi, comportamenti, relazioni e vincoli. Un BO può rappresentare, per esempio, una persona, un luogo, un concetto. La descrizione di un BO può essere espressa in un linguaggio naturale, in un linguaggio formale di modellizzazione o in un linguaggio di programmazione.”
Secondo questa definizione, tipici BO sono i clienti, i fornitori, gli ordini, le fatture, i prodotti, i magazzini, i cespiti, etc. Le mutue interazioni tra i BO, innescate da eventi con una significatività aziendale, compongono i processi che modellano il sistema impresa (gestione degli ordini, fatturazione, carico a magazzino, gestione dei cespiti, gestione dei flussi di cassa, etc). Le entità che originano i BO sono le funzionalità richieste in azienda, le relazioni tra queste, i processi di business e gli eventi.
Un BO può essere concepito come un blocco rappresentativo di funzionalità applicative che viene dislocato ed utilizzato in contesti differenti – sia come elemento indipendente, sia in congiunzione con altri BO – per fornire servizi informativi agli utenti. Le funzionalità applicative in un’azienda possono essere generate da varie fonti, ma assumono due nature: sono tangibili, ovvero sostenute e documentate da un medium dotato di consistenza fisica (le informazioni cartacee o elettroniche), o intangibili, cioè si stabiliscono tra le varie entità aziendali solo per il fatto che queste emergono ed interagiscono nello svolgimento dei processi.
Le funzionalità tangibili sono tali proprio perché sono state individuate con precisione e rappresentate, tramite un mezzo fisico univocamente accettato, sia in modo formale sia in modo informale. Esse si riferiscono ad attività che, di norma, sono di tipo operativo e a questa categoria si possono far risalire, per esempio, gli ordini di acquisto o di vendita, i resoconti finanziari, le fatture, le comunicazioni interne, la posta (elettronica o cartacea) in arrivo o in partenza, etc. Le funzionalità intangibili sono più sottili e delicate poiché, spesso, sono relative a processi e relazioni essenziali per la sopravvivenza e la competitività dell’azienda (le cosiddette attività mission-critical).
Per quanto concerne le altre due entità generatrici di BO, si osservi che i processi riguardano tutta la gestione aziendale, coinvolgendo gli ordini, le vendite, la produzione, il controllo della qualità, le transazioni finanziarie, la logistica in entrata ed in uscita, etc.; le relazioni emergono naturalmente poiché l’azienda, in quanto sistema economico-sociale aperto e comunicante, stimola la nascita di interazioni tra le risorse umane, i clienti, la forza commerciale, etc.
I BO possono essere costruiti anche intorno agli eventi più significativi della vita aziendale, quali: la chiusura mensile o annuale dei conti, il lancio di una nuova campagna di marketing, l’attivazione di una particolare linea di credito, etc. In questo caso essi non rappresentano funzionalità o processi o relazioni, bensì avvenimenti, talvolta eccezionali, ritenuti di rilevanza essenziale per la gestione aziendale.
Qualunque entità rappresentino, i BO sono, dal punto di vista dello sviluppatore, delle strutture informative che incapsulano in un modulo software le regole e le relazioni che intervengono nei processi aziendali: le regole determinano i comportamenti degli oggetti nel loro contesto ambientale (di business); le relazioni (anche conflittuali) si originano in funzione dell’interazione di un oggetto con le entità ambientali (altri oggetti o utenti o eventi) e stabiliscono le potenzialità dell’oggetto.
Lo studio dei BO, esaurita la componente definitoria, può concentrarsi su un insieme di caratteristiche, la composizione del quale è molto varia in funzione del grado di approfondimento dell’analisi e del retroterra culturale dell’analista. In questa trattazione si considerano quattro proprietà – da intendersi come “cardinali”, cioè fondamentali per lo studio successivo – che, data la loro immediatezza, possono contribuire ad illuminare il neofita nella comprensione dei BO.
Una delle caratteristiche principali di un oggetto, che riguarda la sua composizione, è il grado di granularità, una valutazione dell’articolazione strutturale interna che può assumere almeno tre valori crescenti: componente, contenitore o composito (o composto).
Un oggetto è detto componente quando si ritiene che possa essere utilizzato nella costruzione di un altro BO (questo concetto è simile a quello di subroutine utilizzato in programmazione). Gli oggetti componenti non sono necessariamente oggetti banali: essi possono spaziare dal semplice calcolo di uno sconto per quantità ad una procedura di controllo del credito per giungere sino ad un’analisi di profittabilità realizzata con sofisticati metodi matematici. Il tratto distintivo principale di un oggetto componente è la sua transitorietà: essi sono attivati da un input, lo elaborano, producono un output e si riportano in uno stato di quiescenza. Ne discende che il contributo che apportano alla conoscenza dei problemi aziendali è frutto solo del periodo di attività del comportamento dell’oggetto.
Un oggetto contenitore avvolge, gestisce e contiene altri BO ed è, dunque, un tipo di oggetto appartenente ad una categoria di complessità superiore alla precedente, poiché incapsula in sé almeno la somma delle conoscenze degli oggetti contenuti incrementata di un’ulteriore quota dovuta alle modalità di interazione e di gestione dei componenti. Un buon esempio di un oggetto contenitore è costituito dai documenti composti da testi, grafici, tabelle di calcolo, immagini e suoni, quali sono i compound document resi disponibili dai maggiori produttori di software. A rigor di termini, un contenitore non è un vero BO poiché il suo scopo consiste nell’armonizzazione di una complesso di oggetti, coordinandone i comportamenti ma prescindendo dal contesto (si veda nel seguito il significato di questo termine). Questo non significa che non sia possibile costruire delle applicazioni, anche potenti, tramite i contenitori ma che la responsabilità della comprensione del contesto implicato dall’oggetto è demandata all’utente.
Gli oggetti compositi sono l’espressione più alta della granularità e costituiscono gli esempi più emblematici della categoria dei BO. Un oggetto di questa specie è costituito da componenti, contenitori e da una certa quota di intelligence che rendono la combinazione molto più potente ed espressiva della semplice “addizione” delle parti. Si ottiene un fenomeno sinergico simile a quello di certe leghe metallurgiche, che presentano delle caratteristiche fisiche e chimiche notevolmente superiori alla semplice combinazione lineare di quelle corrispondenti dei materiali elementari.
La seconda caratteristica dei BO, precedentemente accennata ma lasciata all’interpretazione intuitiva, è quella del contesto. Con questo termine si intende la posizione di un oggetto in un processo di business oppure il ruolo che esso gioca nella costruzione di un BO contenitore. Ben pochi BO hanno una significatività in uno stato di perfetto isolamento ambientale: essi, non avendo alcuna rilevanza agli effetti dei processi aziendali, sarebbero completamente inutili e la loro esistenza risulterebbe ingiustificata. Talvolta questa singolarità esistenziale potrebbe essere addirittura dannosa poiché contribuirebbero ad aumentare il “rumore ambientale”: l’esistenza di un BO è giustificata solo nel contesto di un processo ed in relazione con gli altri BO che vi partecipano.
I BO, come tutte le entità rappresentative dei fenomeni reali, sono dotati di un’altra caratteristica inalienabile: il ciclo di vita. Una volta creato, un BO inizia il suo ciclo vitale cambiando il proprio stato ed è importante comprendere le implicazioni di questa evoluzione, poiché ogni transizione può innescare degli eventi che influenzano sia l’oggetto sia stesso sia quelli a questo correlati nei processi di business.
L’ingresso dell’OT nel mainstream tecnologico ha creato molte aspettative da parte del mercato, sostenute ed attivate dai “boatos” di marketing. In realtà, pur essendo l’OT una disciplina che data dal lontano 1967, con la definizione del linguaggio Simula, molto spesso i conclamati “plug-and-play” si trasformano in strazianti “plug-and-pray” (dopo essere transitati, tutti, nello stato “plug-and-pay”). Queste delusioni sono originate, soprattutto, dalla superficialità degli approcci adottati per attualizzare il paradigma proposto dall’OT in una certa realtà aziendale, spesso caratterizzata da una cultura d’impresa inadeguata all’innesto tecnologico. Nonostante ciò, l’OT non è l’ennesimo sogno di visionari, bensì una mondo in creazione e consolidamento intorno ad un nucleo di concetti, di proposte e di soluzioni standard che agiscono da catalizzatori per l’interoperabilità.
Dal punto di vista commerciale, l’OT viene ampiamente utilizzata, da molti anni, in diversi settori ed in primo luogo quelli di natura strettamente tecnologica. Sono molti, infatti, i moduli appartenenti alla categoria del software di base o dei tool di sviluppo avanzati (CASE, CAD, CAM, CAE, Sistemi Operativi) concepiti e realizzati impiegando l’OT. I BO, in particolare, possono trovare vasti campi d’applicazione nella creazione di sistemi software complessi, realizzando in tal modo i concetti dell’attuale corrente filosofica imperante nel mondo dello sviluppo applicativo: la composizione per parti (o per componenti) del software. I BO si propongono, infatti, come candidati ideali per lo sviluppo di applicazioni wrapper atte a recuperare, in ottica OT, i sistemi software sviluppati in passato (i legacy system). Essi, inoltre, possono essere utilizzati per la costruzione di “mini-applicazioni” autoconsistenti (simili alle app diffusissime nel mondo del Mobile Computing) destinate ad operare singolarmente o in armonia con altri moduli software.
Un altro impiego dei BO può essere individuato nella costruzione di librerie di classi, una sorta di collezione di “matrici software” alla quale attingere per costruire oggetti complessi grazie alle trasformazioni di generalizzazione o specializzazione. Questi oggetti-archetipo, acquistati o costruiti e perfezionati nel tempo, diventeranno presumibilmente un asset aziendale, poiché, se adeguatamente ingegnerizzati, si propongono come gli elementi portanti per il consolidamento del patrimonio di conoscenze dell’impresa, la vera arma competitiva con valenza strategica del futuro.
Affinché possano campionare in modo adeguato la realtà, i BO però devono possedere alcune caratteristiche fondamentali in termini di generalità e di sicurezza.
Innazitutto i BO sono delle entità condivise da una notevole quantità di applicazioni eterogenee e da una molteplicità di utenti con esigenze informative diverse. Per esempio, un oggetto che rappresenta un ordine di vendita è un’entità interessante per vari dipartimenti aziendali, quali l’area delle vendite, la produzione, il marketing, l’amministrazione. E’ facile immaginare, dunque, che la descrizione dell’oggetto, consolidata nella classe dalla quale questo deriva, debba essere estremamente esaustiva per rappresentare tutti gli aspetti organizzativi indotti dai vari processi di business.
Appunto perché sono entità condivise – e, spesso, vitali per l’azienda – sia i BO stessi sia l’ambiente operativo che li sostiene devono essere garantiti da un adeguato meccanismo di sicurezza, articolato su vari livelli. Si rendono necessari, per esempio: degli schemi di autenticazione e di autorizzazione; dei meccanismi di controllo delle versioni; dei sistemi di firewall anti-intrusione, sia questa accidentale o intenzionale; un ambiente operativo fault tolerant generalizzato e coerente tra le varie piattaforme applicative; un tool di system management sofisticato e sensibile che sappia intercettare in tempo utile tutte le anomalie e reagire in maniera anticipatoria.
Dal “brodo primordiale” dell’OT stanno emergendo forme di vita superiore. Affinché questo sforzo evolutivo abbia successo, esso deve essere sostenuto e protetto da tutti gli attori che interpretano un ruolo decisivo sul mercato delle tecnologie dell’informazione. Utenti, sviluppatori e case produttrici devono partecipare congiuntamente allo sviluppo dell’OT, coagulando l’interesse e gli indirizzi di ricerca e sviluppo intorno alla definizione ed alla realizzazione di standard terminologici, concettuali ed operativi che consentano la massima interoperabilità – o meglio, la massima interscambiabilità – tra i prodotti e le soluzioni applicative. Questa è una questione vitale per ogni evoluzione tecnologica: le imprese sono oberate da problemi di business e mostrano una crescente insofferenza nei confronti di tecnologie che, pur proclamandosi innovative, producono, in realtà, un incremento della complessità dei problemi piuttosto che contribuire alla realizzazione efficiente dei processi di business.
Gian Franco Stucchi
