2009-12-22 18 views
7

Che cosa preferisci (dal punto di vista del tuo sviluppatore) quando si tratta di implementare un processo di business?BPMS o semplicemente programmazione?

Un Business Process Management System (BPMS) o solo il tuo IDE preferito con gli strumenti e le strutture necessarie (uno strumento di segnalazione per esempio)?

Qual è dal tuo punto di vista il più grande vantaggio di un BPMS rispetto a un IDE con i tuoi strumenti e strutture personali?

OK. Forse dovrei essere più specifico ... Ho avuto modo di conoscere uno specifico BPMS che dovrebbe facilitare l'implementazione di un processo aziendale configurando le regole. Ma per me come sviluppatore è difficile lavorare con il sistema. Mi piacerebbe lavorare con file di testo che posso refactoring e mi piacerebbe poter scegliere la tecnologia o la struttura giusta per il lavoro che devo svolgere. Invece il sistema mi obbliga a configurare.

Ci sono regole dove posso usare Java, ma anche allora devo attenersi a l'editor sistemi senza intellisense ecc

Quindi questo mi porta alla risposta della mia domanda - vorrei utilizzare il strumenti a cui sono abituato invece di dover imparare come lavorare con un BPMS (almeno quello che conosco) perché mi limita più di quanto non aiuti. Il BPMS che conosco è un framework dal quale è difficile sfuggire! A questo punto, preferirei un framework come Grail su qualsiasi BPMS che conosca.

Quindi forse la domanda più specifica è: ti senti lo stesso o ci sono BPMS che ti supportano nello sviluppo di uno sviluppatore e pensi come uno sviluppatore o la maggior parte di loro ti costringono a fare il tuo lavoro in un modo diverso?

+0

vedere anche http://stackoverflow.com/questions/214122/is-bpm-in-your-mind – rdmueller

risposta

7

Non sai cosa esattamente chiedi, ma la scelta del BPM rispetto alla programmazione normale dipenderà dai requisiti. Un "processo aziendale" è un termine relativamente vago nell'ingegneria del software.

Ecco alcuni criterio per valutare le vostre esigenze:

  • complessità delle norme - sono le decisioni/norme incarnata nel vostro processo semplice, complicato, configurabile, hard-coded?
  • volatilità del processo - Con quale frequenza cambia il processo? Chi dovrebbe essere in grado di fare il cambiamento?
  • necessità di integrazione - Il processo è realizzato utilizzando più servizi eterogenei o è stato implementato nella stessa lingua?
  • sincrono/asincrono - Il processo è "a esecuzione prolungata" con la necessità di gestire azioni asincrone?
  • human tasks - Il tuo processo implica l'interazione umana, con attività assegnate/indirizzate alle persone in base ai loro ruoli/responsabilità?
  • monitoraggio del processo - Qual è il livello di controllo desiderato per le istanze di processo esistenti in esecuzione? Hai bisogno di controllare le azioni, ecc.?
  • gestione errori - In base ai punti precedenti, come si intende gestire gli errori o riprovare l'esecuzione di un processo errato?

A seconda della risposta a queste domande, si può capire che il processo è più vicino a un grafico simple state con poche azioni e decisioni che possono essere eseguite in una sequenza, oppure si può capire che avete bisogno di qualcosa di più elaborato e che non vuoi reimplementare tutto da solo.

Tra programmazione semplice e full-fledge soluzione BPM (ad esempio Oracle BPM suite che contiene BPEL, rule engine, ecc), ci sono soluzioni intermedie come jBPM o Windows Workflow Foundation e probabilmente molti altri. Queste soluzioni intermedie sono spesso un buon compromesso.

4

BPMS-- un sacco di casi aziendali comuni, i casi d'uso sono già stati implementati. Quindi devi solo sapere come usarlo. Per un flusso di lavoro comune, non è nemmeno necessario scrivere una singola riga di codice, anche se per lo più dovresti scrivere alcuni script per coprire aspetti che non sono ancora stati implementati.

Programmazione semplice: basta utilizzare l'IDE per eseguire il codice. Il lato positivo: più controllo. Il negativo? Molte volte vengono spese per la riscrittura del codice boilerplate. E tu devi mantenerli.

Quindi, in breve, preferirei un sistema di gestione dei processi aziendali. Uno che vorrei raccomandare è ProcessMaker. È dotato di un progettista di processo intuitivo che consente di progettare il flusso di lavoro con il trascinamento della selezione. E puoi sempre scrivere trigger per estendere le funzionalità di processo. È anche open source.

+1

In questo modo si ottiene un avvio migliore con un BPMS poiché si dispone già del sistema e non è necessario cura della schermata di login, gestione delle sessioni ecc ... Ma se devi implementare molti processi, è ancora valido? Intendo con il primo processo, hai implementato il codice boilerplate che puoi riutilizzare per il secondo ... – rdmueller

+1

Sì, con BPMS è ancora più veloce andare – Graviton

10

In base alla mia esperienza, gli ambienti di sviluppo forniti dai sistemi BPMS sono di terza portata, improduttivi e praticamente ti costringono a scrivere codice difficile da gestire, mal progettato (a causa dei loro limiti). Quasi tutte le "funzionalità" (interfaccia utente, integrazioni, ecc.) Fornite dal sistema BPMS a cui sono abituato (quella venduta da quella società chiamata per il suo database) non valevano i soldi che abbiamo pagato.

Se si è costretti a utilizzare BPMS, come sviluppatore, il mio consiglio sarebbe quello di creare gran parte della propria applicazione in un ambiente di sviluppo convenzionale, come Java o .Net, creare il meno possibile nell'ambiente BPMS stesso, e integrare i due. L'unica cosa che dovrebbe andare nel BPMS è il minimo per far funzionare il processo aziendale.

+0

Anche questa è la mia esperienza. L'unico problema che vedo è che non esiste un'interfaccia pulita tra un motore di workflow e lo sviluppo convenzionale. E immagino che non ci possa essere, perché entrambi (il flusso di lavoro e l'applicazione) cercano di guidare il flusso ... – rdmueller

8

Ho lavorato con Biztalk in passato e più recentemente con JBPM. La mia opinione è prevenuto contro BPM per i seguenti motivi:

  1. ripida curva di apprendimento: per far funzionare un processo, devo capire come funziona il sistema e le opere dell'editor. È abbastanza difficile per uno sviluppatore capire il sistema, per non parlare di un utente aziendale. Il drag and drop e la rappresentazione visiva sono un ottimo strumento demo. Sicuramente colpisce i manager (che alla fine pagano per questo), ma la produttività di uno sviluppatore cala.

  2. Non sviluppatori che modificano il flusso di lavoro: non ho visto una soluzione BPM funzionare in modo impeccabile. Sebbene non assomigli al codice, fai clic con il pulsante destro del mouse sulla casella e devi inserire del codice, altrimenti non funzionerà. Quindi hai sicuramente bisogno di uno sviluppatore per farlo. La parte migliore è che non è né sviluppatore né amichevole per l'utente, ma solo per la demo.

  3. Testabilità e refactoring: è praticamente impossibile testare un BPMS. Avete pubblicizzato "framework di test unitari", ma la maggior parte di questi sono hacker e difficili da usare.Recentemente ho provato quello di JBPM; Ho finito per scrivere un sacco di codice di colla e gestori di flussi di lavoro falsi per farlo funzionare. L'accordo per me è un refactoring. Se il business cambia radicalmente, pensa a come dovrebbe apparire un processo di business, quindi buona fortuna ri-organizzare le scatole, perché solo riorganizzarle non funzionerà, anche tutte le variabili legate alle scatole devono essere riorganizzate. Preferirei il potere dell'IDE e testare per refactoring il mio processo di business.

Se l'applicazione dispone di flusso di lavoro, allora si potrebbe provare una libreria del flusso di lavoro (con o senza stato persistente). Gestirà comunque i tuoi flussi di lavoro senza tutto il peso che viene fornito con un BPM. Se un utente aziendale ha bisogno di capire il codice, allora lascia che l'azienda prepari buoni diagrammi di flusso del processo e li traduca in un buon codice basato sul dominio. Utilizza i test di accettazione stile cetriolo per far incontrare gli sviluppatori e il business. Un BPM è solo qualcosa che cerca di fare troppe cose e finisce per fare tutte quelle cose male.