Software Architecture, ESB e BPM

Da qualche settimana, nel mio contesto lavorativo, si è aperta una interessante e stimolante discussione sull’adozione di un ESB (Enterprise Service Bus) e/o uno strumento di BPM (Business Process Management).

Generalmente, la scelta tra l’uno o l’altro, dipende da un mix di fattori tecnici e non tecnici: know-how, partnership aziendali, costi, ecc. Volendo essere un po’ più metodici, però, bisognerebbe prima di tutto rispondere a due domande ben specifiche:

  • Come scelgo oggettivamente se utilizzare un BPM o un ESB?
  • Ha senso utilizzare contemporaneamente un BPM ed un ESB all’interno della stessa architettura enterprise?

Cominciamo con il dare una risposta, sicuramente non esaustiva ma sufficientemente indicativa, alla prima domanda, presentando le peculiarità dei due strumenti oggetti della contesa.

Una piattaforma di Business Process Management è pensata per assistere i Business Analyst nell’attività di automatizzazione dei processi di lunga durata, e, come tale, è tipicamente human centric oriented. In tale scenario le prestazioni non sono un fattore chiave e i tempi di latenza non vanno ad inficiare l’efficacia del processo stesso.

Tutte le soluzioni BPM esistenti hanno in comune un set minimo di funzionalità che consentono di: definire il processo, governare la relativa esecuzione ed effettuarne il monitoraggio. Chiaramente, il tutto avviene orchestrando attori con responsabilità diverse e sistemi eterogenei, anche se il supporto a protocolli di comunicazione e al formato dei dati è alquanto limitato. Un esempio efficace di utilizzo di una soluzione BPM può essere la gestione dei processi di HR all’interno di una media-grande azienda.

esb-bpm bpm example

Esempio di definizione di un processo BPM

Dualmente, un Enterprise Service Bus (ESB) è ottimizzato per massimizzare le prestazioni in situazioni di carico particolarmente elevato, garantendo un comunicazione real-time machine centric.  Inoltre, quasi tutti gli ESB offrono un supporto esteso a molti protocolli di comunicazione e tipologie di dati.

esb-bpm esb example

Schema concettuale di un ESB

Le caratteristiche appena citate suggeriscono che un ESB trova la sua naturale applicazione laddove è necessario garantire alte performance, integrando fonti eterogenee di dati senza l’intervento della componente umana.

Vediamo ora di rispondere alla seconda domanda, ovvero: ha senso utilizzare contemporaneamente un BPM e un ESB? In linea di massima entrambi gli strumenti introducono una complessità non irrilevante all’interno di un’architettura enterprise, per cui è preferibile utilizzarli in modo esclusivo ed esclusivamente laddove sono realmente necessari, avendo rilevato oggettivi benefici dal loro utilizzo.

Un utilizzo combinato, relativamente comune, dei due strumenti è l’orchestrazione automatizzata di più processi BPM, in cui i risultati sono condivisi da diversi servizi consumer.

esb-bpm bpm over esb

BPM over ESB

Risulta anche valida, per controllare le performance e gestire più accortamente gli SLA, la soluzione diametralmente opposta, in cui l’ESB diventa il canale di comunicazione tra i diversi sistemi impegnati nell’espletamento di un processo BPM.

esb-bpm esb over bpm

ESB over BPM

Sperando di aver dato un’idea di quelle che sono le differenze basilari di un BPM e di un ESB, è importante sottolineare ulteriormente (leggasi qui) che l’utilizzo di tali soluzioni è da valutare minuziosamente, al fine di evitare l’introduzione di un overhead tecnologico laddove non è realmente necessario.

agileiot logo  ac2 logodac dac dacdac dac psmii psmii safe cal1 less certazure fundamentals
mvp reconnect

Free Joomla templates by Ltheme