Professional Documents
Culture Documents
Nell’attuale scenario mondiale BPM e SOA sono due temi architetturali di notevole
importanza nell’ambito dei prodotti software e delle architetture.
In realtà sebbene si possa avere SOA senza BPM come in un sistema ESB (Enterprise
Service Bus) o un BPM senza SOA, tuttavia l’utilizzo combinato delle due opportunità
concettuali offre notevoli vantaggi nelle infrastruttura middleware di una azienda,
specie se di grandi dimensioni.
In ambito mondiale l’OMG ha esposto i criteri per ben sposare SOA e BPM e
migliorare l’efficienza e la flessibilità del business aziendale.
E’ da ricordare che uno dei primi approcci usati per ottenere dei risparmi economici
immediati, è stato quello di far uso di “prodotti monolitici” o “prodotti buy”
rinunciando in prima battuta ai “prodotti make”; ma ciò richiede necessariamente ad
un’azienda di adattare i processi aziendali, ridisegnarli e semplificarli per quello che
offre il prodotto acquistato, ma anche di attendere tempi lunghi di aggiornamento del
prodotto da parte del vendor per i miglioramenti e l’evoluzione secondo il proprio
business.
C’è anche da dire che questo tipo di modello di adattamento del business al prodotto
software e non il viceversa può andar bene in un mercato ben assestato e poco
dinamico; mal si adatta difatti ad aziende che ben agguerrite offrono nuove proposte
di servizi e prodotti.
Quindi sono tre gli elementi chiave per avere una architettura di successo SOA:
definire con precisione le informazioni su cui un
servizio opera, i cosiddetti "metadati del servizio";
definire con cura, semplicità e senza ridondanza i metadati aziendali,
attraverso uno standard basato su XML (SID, BVI, etc)
progettare l’ "orchestrazione di servizi"; il che
definisce esattamente come un insieme di servizi viene utilizzato in
un workflow (insieme di task in sequenza, parallelo, con sincronizzazione etc)
per di realizzare un particolare processo di business.
Tutto quello di cui sopra è oggi sostenuto da metodologie open e strumenti a supporto
delle metodologie stesse.
Il primo passo da fare per andare nella direzione BPM & SOA è la discovery dei propri
processi, automatizzati e manuali. Occorre catturarli e documentarli. L’OMG propone
di orientarsi col Business Process Maturity Model (BPMM) e il Business Process
Modeling Notation (BPMN).
BPMM è diviso in cinque livelli di maturità che rappresentano gli stati differenti
attraverso cui l'organizzazione evolve ed è trasformata:
evoluzione dei processi da mal definiti e con pratiche incompatibili (livello 1),
pratiche ripetibili a livello di workgroup (livello 2),
standard di business a livello di organizzazione end to end dei processi (Livello
3),
a processi gestiti e statisticamente prevedibili (Livello 4)
innovazione di processo continuo e ottimizzazione (livello 5).
Business Process Modeling Notation (BPMN) integra BPMM fornendo uno standard,
una notazione di semplice lettura visiva per documentare i processi di business.
BPMN è a sua volta sostenuto dal Business Process Definizione Metamodel (BPDM),
una specifica che fa da ponte tra BPMN e strumenti software che creano
orchestrazione software mediante Model Driven Architecture (MDA).
Un modo per affrontare tale fatto è il Semantic Business Vocabulary Rules (SBVR), un
vocabolario che definisce la semantica e le regole di business, e che si avvicina per
semplicità al linguaggio naturale degli operatori.
Soprattutto si possono creare dei Business Rules Engine (BRE), il cui compito è quello
di essere dei Directory Rules attivi, che se interrogati dai sistemi sono in grado di
fornire la regola di business da applicare in quella situazione (statica o dinamica), ad
un BPM, ad un ESB o un sistema di trasformazione ETL.
Esistono molti prodotti oggi che affrontano tali tematiche delle regole e la
realizzazione di BRE (ad esempio ILOG dell’IBM, etc).