BPMS o semplice programmazione?

Question

Cosa preferisci (dal punto di vista del tuo sviluppatore) quando si tratta di implementare un processo aziendale?

Un sistema di gestione dei processi aziendali (BPMS) o semplicemente il tuo IDE preferito con gli strumenti e i framework necessari (ad esempio uno strumento di reporting)?

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

OK.Forse dovrei essere più specifico...Ho conosciuto uno specifico BPMS che dovrebbe semplificare l'implementazione di un processo aziendale configurando le regole.Ma per me come sviluppatore è difficile lavorare con il sistema.Vorrei lavorare con file di testo di cui posso effettuare il refactoring e vorrei poter scegliere la tecnologia o il framework giusto per il lavoro che devo svolgere.Invece il sistema mi obbliga a configurare.

Ci sono regole in cui posso usare Java, ma anche in questo caso devo attenermi all'editor di sistema senza intellisense ecc.

Quindi questo mi porta alla risposta alla mia domanda: vorrei utilizzare gli strumenti a cui sono abituato invece di dover imparare a lavorare con un BPMS (almeno quello che conosco) perché mi limita più che aiuta .Il BPMS che conosco è un quadro dal quale è difficile uscire!In questo momento, preferirei un framework come Grail rispetto a qualsiasi BPMS che conosco.

Quindi forse la domanda più specifica è:ti senti lo stesso o ci sono BPMS che ti supportano nell'essere uno sviluppatore e pensare come uno sviluppatore o la maggior parte di essi ti costringe a svolgere il tuo lavoro in un modo diverso?

Answer 1

Non sei sicuro di cosa esattamente si chiede, ma la scelta BPM vs. programmazione pianura dipenderà dalle esigenze. Un "processo di business" è un termine relativamente vago in ingegneria del software.

Ecco alcuni criterio per valutare le vostre esigenze:

• complessità delle norme - sono le decisioni e / o norme contenuti nel vostro processo semplice, complicato, configurabile, hard-coded
?
• volatilità del processo - come spesso fa, il vostro processo di cambiamento? Chi dovrebbe essere in grado di fare il cambiamento?
• integrazione devono -? È il tuo processo realizzato utilizzando più servizi eterogenee, oppure è tutto implementato nella stessa lingua
• sincrono / asincrono -? È il tuo processo "long-running" con la necessità di gestire azioni asincrone
• attività umane - Il vostro processo coinvolge l'interazione umana, con mansione assegnata / indirizzati a persone in base al loro ruolo / responsabilità
?
• il monitoraggio del processo - Qual è il livello di controllo che si desidera per le istanze di processo esistenti in corso di esecuzione? Avete bisogno di controllare le azioni, ecc?
• la gestione degli errori -? A seconda dei punti precedenti, come si prevede di trattare gli errori, o ripetere di esecuzione dei processi difettoso

A seconda della risposta a queste domande, si può capire che il processo è più vicino a un stato semplice grafico con un paio di azioni e decisioni che possono essere eseguiti in una sequenza, oppure si può capire che avete bisogno di qualcosa di più elaborato, e che non si vuole re-implementare tutto ciò che da soli.

tra programmazione semplice e pieno-fledge soluzione BPM (ad esempio Oracle BPM Suite che contiene BPEL , motore di regole, ecc), ci sono soluzioni intermedie come < a href = "http://www.jboss.com/products/jbpm/" rel = "noreferrer"> jBPM o Windows Workflow Foundation e probabilmente un sacco di altri. Questi soluzione intermedia sono spesso buoni trade-off.

Answer 2

Nella mia esperienza gli ambienti di sviluppo forniti dai sistemi BPMS sono di terza categoria, improduttivo, e praticamente ti costringono a scrivere difficile da mantenere, mal codice progettato (a causa delle limitazioni). Quasi tutte le "caratteristiche" (UI, integrazioni, ecc) forniti dal sistema BPMS ho familiarità con (quello venduto da tale società chiamata per la sua base di dati) non erano vale i soldi che abbiamo pagato.

Se si è costretti a usare BPMS, come sviluppatore, il mio consiglio sarebbe quello di costruire, come gran parte della vostra applicazione in un ambiente di sviluppo convenzionale, come Java o .Net, costruire il meno possibile l'ambiente in sé BPMS , e integrare i due. Le uniche cose che dovrebbero andare nella BPMS è il minimo per far funzionare il processo di business.

Answer 3

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

1. Ripida curva di apprendimento :Per far funzionare un processo, devo capire come funzionano il sistema e l'editor.È già abbastanza difficile per uno sviluppatore comprendere il sistema, per non parlare di un utente aziendale.Il trascinamento della selezione e la rappresentazione visiva sono un ottimo strumento dimostrativo.Sicuramente impressiona i manager (che alla fine ne pagano le spese), ma la produttività di uno sviluppatore semplicemente diminuisce.

2. Non sviluppatori che modificano il flusso di lavoro:Non ho visto una soluzione BPM farlo in modo impeccabile.Anche se non sembra 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é facile da usare per gli sviluppatori né facile per l'utente aziendale, ma solo facile da usare in versione demo.

3. Testabilità e refactoring:È praticamente impossibile testare un BPMS.Sono pubblicizzati "framework di test unitari", ma la maggior parte di essi sono hack e difficili da usare.Recentemente ho provato quello JBPM;Ho finito per scrivere un sacco di codici collanti e falsi gestori di flussi di lavoro per farlo funzionare.Il problema per me però è il refactoring.Se l'azienda cambia radicalmente idea su come dovrebbe apparire un processo aziendale, allora buona fortuna nel riorganizzare le scatole, perché semplicemente riorganizzarle non funzionerà, anche tutte le variabili legate alle scatole devono essere riorganizzate.Preferirei la potenza dell'IDE e dei test per rifattorizzare il mio processo aziendale.

Se la tua applicazione dispone di un flusso di lavoro, puoi provare una libreria di flussi di lavoro (con o senza stato persistente).Gestirà comunque i tuoi flussi di lavoro senza tutto il peso derivante da un BPM.Se un utente aziendale ha bisogno di comprendere il codice, lascia che sia l'azienda a preparare buoni diagrammi di flusso dei processi e a tradurli in un buon codice basato sul dominio.Utilizza test di accettazione in stile cetriolo per riunire gli sviluppatori e l'azienda.Un BPM è semplicemente qualcosa che cerca di fare troppe cose e finisce per farle tutte male.

Answer 4

BPMS-- un sacco di buon business case, casi d'uso sono già implementati. Quindi devi solo sapere come usarlo. Per flusso di lavoro comune, non hanno nemmeno bisogno di scrivere una sola riga di codice, anche se per lo più si sarebbe dovuto scrivere alcuni script per coprire le cose che non sono ancora implementate.

Plain programming-- basta usare l'IDE di incidere il codice. Il lato positivo: maggiore controllo. Il negativo? Un sacco di volte sono spesi per riscrivere il codice boilerplate. E bisogna mantenerli.

Quindi, in poche parole, io preferirei un sistema di Business Process Management. Uno che mi sento di raccomandare è ProcessMaker . È dotato di un design processo intuitivo che permette di progettare il flusso di lavoro con il drag and drop. E si può sempre scrivere grilletto di estendere le funzionalità di processo. E 'open source pure.