BPM, SOA e Business Rules Engine, l’ultima frontiera

ing. R. Turco (rosario_turco@virgilio.it)

Nell’attuale scenario mondiale BPM e SOA sono due temi architetturali di notevole
importanza nell’ambito dei prodotti software e delle architetture.

Il termine BPM è l’acronimo di “Business Process Management” mentre SOA è

l’acronimo di “Service Oriented Architecture”.

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.

Lo scopo dell’utilizzo di un BPM in un’azienda è molteplice:

 come tecnica di discovery e di documentazione dei processi aziendali
 per iniziare un costante miglioramento dei processi di business come
semplificazioni architetturali dei servizi ed un miglioramento delle prestazioni
offerte
 per iniziare ad avere architetture che rendano possibile un rapido time-to-
market adeguato al servizio da offrire e alla situazione aziendale

Anche la SOA ha guadagnato un notevole seguito per la sua capacità di:

 offrire una tecnica di disegno dei servizi auto-consistenti
 offrire un miglioramento nell’agilità del business process nelle fasi di
cambiamento dei requisiti e di miglioramento delle infrastrutture, guidando
verso la rapidità e la ripetibilità del processo

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.

Spesso non è possibile adattarsi al prodotto e occorrono interventi di customizzazione

o interventi manuali, che introducono inefficienza ed errori e le parti separate
dell’organizzazione mal si integrano a causa di prodotti troppo “monolitici e silos di
dati” appartenenti a vendor differenti.

Tutto questo mina la necessità primaria di “automatizzare i propri processi di business

in modo semplice ed efficiente”.

La Service Oriented Architecture facilita un approccio di creazione di servizi di

business modulari e indipendenti, ognuno dei quali esegue una
funzione specifica di business e ben definita.

Se si riesce a realizzare in termini SOA servizi elementari e auto-consistenti,

esponibili una sola volta sul middleware, sarà sufficiente assemblarli e orchestrarli
con un BPM. Con diversi assemblaggi delle funzionalità auto-consistenti si possono
ottenere processi di business diversi, facendo riuso dei servizi disponibili.

Se accento a questo si affianca un buon catalogo/Repository (statico inizialmente,

dinamico successivamente come gli UDDI), si ottiene un’ottima documentazione di
tutti i servizi aziendali.

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 fornisce un modello di riferimento, una roadmap, per valutare i processi

all'interno dell'impresa e contribuire a migliorare la loro priorità e importanza.
Esso descrive un percorso guida evolutivo di miglioramento
valutando un percorso dei processi che va da processi immaturi,
processi incoerente a da maturare, processi disciplinati.

Il BPMM è basato sull’originale processo di maturità di Watts Humphrey e rispettato

dal Capability Maturity Model Integration (CMMI) nato per aiutare le organizzazioni
per realizzare processi di ingegneria ripetibili in ambito software e per valutare i
rischi nello sviluppo e la distribuzione del software.

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).

Il raggiungimento di ogni livello di maturità comporta che siano soddisfatti tutti i

requisiti dei livelli inferiori.

Business Process Modeling Notation (BPMN) integra BPMM fornendo uno standard,
una notazione di semplice lettura visiva per documentare i processi di business.

BPMN è destinato ad essere utilizzato direttamente da persone dell’azienda per

progettare, gestire e realizzare i processi di business, ma al tempo stesso con la
precisione sufficiente per consentire ai diagrammi BPMN di essere tradotti in
software che orchestra i singoli servizi per realizzare dei processi di business
specifici.
Questa metodologia di solito è supportata da strumenti RAD che consentono di
modellare i processi di business, di documentarli e di produrre software per il
deploying su una piattaforma software (es: BusinessStudio della TIBCO con la sua
suite IProcess).

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).

BPDM fornisce, in pratica, un comune vocabolario, indipendente da qualsiasi

tecnica/tecnologia, per concetti di processi di business, degli schemi standardizzati
che sono memorizzabili e scambiabili tra prodotti di diversi vendor.

Un ulteriore elemento chiave nell’ambito degli standard aperti è di definire

esattamente quali dati ogni servizio offre e richiede, ed esattamente come queste
informazioni sono manipolato dal servizio.

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.

Con un linguaggio/modello SBVR abbastanza preciso si possono avere strumenti per

controllare automaticamente vocabolari e regole per la verifica della
coerenza, rilevando termini indefiniti, incongruenze e dichiarazioni regola diversa che
si sono sovrapposti significati.

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).