Qual è il valore degli strumenti del flusso di lavoro? [chiuso]

Sono nuovo nello sviluppo del flusso di lavoro e non credo di ottenere davvero il "quadro generale". O forse per dirla diversamente, questi strumenti attualmente non "fanno clic" nella mia testa.

Quindi sembra che alle aziende piaccia creare disegni di business per descrivere i processi, e ad un certo punto qualcuno ha deciso che potevano usare una macchina a stati come un programma per controllare effettivamente i processi da una linea e scatole come un diagramma. Dieci anni dopo, questi strumenti sono enormi, estremamente complicati (la mia azienda sta attualmente giocando con WebSphere e ho partecipato ad alcuni corsi di formazione, è un mostro, anche le cosiddette versioni "minimaliste" di questi strumenti di flusso di lavoro come Activiti sono enorme e complicato anche se non altrettanto complicato della bestia che è WebSphere afaict).

Qual è il grande vantaggio nel farlo in questo modo? Riesco a capire che i semplici diagrammi di linee e caselle sono utili, ma queste cose, per quanto ne so, sono linguaggi di programmazione visiva a questo punto, completi di condizionali e loop. I programmatori qui sembrano svolgere una notevole quantità di lavoro nel livello di linee e caselle, che a me sembra un linguaggio di programmazione visiva davvero pessimo e basilare.

Se stai andando così lontano, perché non usare semplicemente una sorta di linguaggio di scripting? Le persone hanno buttato fuori il bambino con l'acqua del bagno? Le linee e le caselle sono state portate a un livello assurdo o non capisco il valore di tutto ciò?

Mi piacerebbe davvero vedere argomenti in difesa di questo da parte di persone che hanno lavorato con questa tecnologia e capire perché è utile. Non vedo il valore in esso, ma riconosco che sono nuovo anche per questo e potrebbe non averlo ancora capito.

Dal punto di vista di uno sviluppatore, hai ragione nel dire che questi ambienti "visivi" sono davvero difficili da lavorare. I flussi di lavoro di SharePoint 2010, che utilizzo, eliminano tutte le migliori pratiche relative alla creazione di un buon software aziendale: nessun test automatizzato, nessun riutilizzo del codice, software illeggibile ... Qualsiasi cosa più complessa di un modello predefinito può essere dolorosa da mantenere , come stai vivendo.

Ma dal punto di vista aziendale, i flussi di lavoro hanno enormi vantaggi, almeno in teoria. Per citare questo white paper , l'efficienza, la responsabilità, il controllo e la facilità d'uso di un flusso di lavoro automatizzato offrono enormi guadagni di produttività. Immagina quanto sarebbe inefficiente una semplice approvazione o un processo di onboarding senza questa automazione. Inoltre, l'atto stesso di definire un flusso di lavoro è prezioso per un'organizzazione che sta cercando di ottenere il controllo sui propri processi aziendali.

Lo stato attuale del software del flusso di lavoro non è colpa dell'azienda. Vogliono solo semplificare la vita e i flussi di lavoro sono ottimi per questo. Darei la colpa principalmente a noi, dipartimento IT:

1. Per non essere più trasparente con il business su quanto sia complesso e fragile il sistema. Nascondiamo tutta la complessità.
2. Per non essere in grado di "grattarci il prurito" con soluzioni di flusso di lavoro intuitive e semplici. Questo è probabilmente più diffuso nei confronti di grandi pacchetti aziendali come SharePoint e SAP, ma sono migliori delle soluzioni personalizzate disponibili

C'è solo un vero vantaggio, ma è enorme: la separazione delle preoccupazioni .

Quindi, invece di integrare la logica di orchestrazione del processo nel nostro sistema, diventa una configurazione esterna. Una mappa, in sostanza. Puoi cambiarlo (molto di più) in modo indipendente, puoi avere più processi, più versioni di processi, più versioni di più processi in esecuzione allo stesso tempo, e tutto è pronto all'uso in qualsiasi soluzione decente.

Storicamente, il concetto di SoC ha vinto molte volte - a partire dal principio Unix "fai una cosa, ma fai del bene", e applicato ripetutamente - come avere componenti server dedicati come ESB, diversi sistemi di persistenza, memorizzazione nella cache, bilanciamento del carico , monitoraggio, come la divisione di CSS da HTML, ecc.

Il processo aziendale e le sue regole di flusso sono spesso ortogonali ai dati, alle "schermate" dell'interfaccia utente o alla "gerarchia" degli utenti. Quindi, ha perfettamente senso svilupparlo e cambiarlo separatamente dagli altri aspetti del sistema. Questa era la premessa su cui BPM è apparso nei primi anni '90.

Da allora, molti strumenti e linguaggi sono stati creati per supportare questo concetto, con il più noto BPMN , un linguaggio grafico per la creazione di "diagrammi di flusso" che si associano direttamente ai processi. Mentre le persone si lamentano del fatto che è grande e ingombrante (con oltre 100 simboli nel vocabolario) e che sostiene approcci moderni come S-BPM (ha solo 5 simboli di base), l'attuale pratica industriale è quella di attenersi a BPMN o ai suoi derivati, sottoinsiemi o fratelli.

Non sembri soddisfatto di BPMN:

I programmatori qui sembrano svolgere una notevole quantità di lavoro nel livello di linee e caselle, che a me sembra un linguaggio di programmazione visiva davvero pessimo e basilare.

Ma non è poi così male) C'è una teoria dietro. E la versione 2.0 ha preso alcune buone intuizioni dalle carenze 1.0.

Se stai andando così lontano, perché non usare semplicemente una sorta di linguaggio di scripting?

Il paradigma imperativo e i linguaggi di scripting non sono sempre la risposta migliore. Come probabilmente hai visto in linguaggi dichiarativi (come HTML, CSS, SQL, Drools o interni di Nginx, Graddle e Maven, Puppet ecc.) Il codice risultante può essere molto più piccolo e più pulito di una versione scritta in " linguaggio decente, come Java o C ++ ".

Per quanto riguarda l'altro punto:

per quanto ne so, a questo punto sono linguaggi di programmazione visiva, completi di condizionali e loop.

hai esaminato gli eventi e i trigger ? BPMN è una lingua e devi impararla prima dell'uso, o almeno conoscerla.

Sotto il cofano, BPMN è XML, quindi puoi modificarlo manualmente o generarlo. E puoi controllarli versione, perché XML è basato su testo. Tuttavia, solo avere un XML che può essere tradotto in diagrammi di flusso, non sembra che il suo goona ti aiuti, ed è corretto: scrivere il tuo parser o editor perché è un compito difficile e costoso con vantaggi discutibili.

Fortunatamente, ci sono già strumenti sul mercato che lo fanno esattamente.

Activiti è gratuito e abbastanza popolare tra gli sviluppatori e i proprietari di aziende, a causa del suo prezzo iniziale ( zero ), della disponibilità di informazioni e dell'umiltà. L'ultimo punto è davvero unico, in quanto Activi si concentra solo sulla gestione dei processi aziendali, senza cercare di legarti con soluzioni a pacchetto completo. Inoltre, è aperto, quindi devi solo conoscere Java e REST per farlo funzionare. Lo svantaggio è che lato client, integrazione e logica applicativa / aziendale e l'intera architettura sono lasciati allo sviluppatore, quindi se il tuo team di sviluppo è debole, preparati al fallimento. Il costo totale di proprietà può essere sorprendentemente alto per uno strumento gratuito ;)

Dall'altro lato dello spettro c'è Pega (Pega PRPC), il re in carica dei sistemi BPM (secondo Gartner e Forester), che sembra sorprendentemente buono per la sua età. Questo colosso della cucina è persino capace di CRM, OCR e (se non sbaglio) capacità di riconoscimento vocale, analisi predittiva, gestione delle regole di business e editor dell'interfaccia utente WYSIWYG. Viene fornito con un prezzo serio, però. Non solo costa una fortuna, ma tutto lo sviluppo è fatto all'interno di un'app Web, il che significa che devi usare il browser, che è IE8 (oltre ad alcuni plugin, oltre a brutti hack, come usare Excel per modificare le tabelle di dati). Inoltre, la modifica di Java, Javascript o HTML / CSS viene eseguita anche con il browser Web, quindi saluta i test unitari, l'evidenziazione del codice IDE, il refactoring e tutti i tuoi giocattoli di programmazione che ti sei innamorato.

Il suo lato positivo? puoi implementare un sistema complesso ENTRO LE SETTIMANE [ PDF , vedi pagina 22]. E sì, il risultato non è garantito.

Di recente, IBM ha acquisito Lombardi (in linea con il ritmo del tempo aziendale) e ora offre una soluzione molto competitiva (ma poi dovrai comprare tutto , lo sai). Appian è un giovane venditore che ha spunti interessanti e feedback positivi, ma il modo in cui sono scritti (due lingue DSL extra oltre a quella visiva) non mi attira.

Ci sono altri giocatori e le loro soluzioni. Molti di loro sono semplicemente orribili. Tipo: i tuoi occhi, cervello e cuore sanguinerebbero letteralmente, quando li guardi semplicemente. Quindi, fidati del tuo coraggio e non farti odiare dai tuoi sviluppatori e utenti.

Nota di chiusura:

Il sistema BPM è lo stesso per i processi, ciò che Photoshop è per le immagini. Non aver paura che sia visivo. Non farlo fare il lavoro non adatto a questo (ricordi i siti web creati interamente in Photoshop, che erano quasi impossibili da modificare?). Mantienilo semplice e non creare bug;)

Anni fa, prima che nascesse la maggior parte di noi, gli sviluppatori di software dovevano scrivere il proprio codice per archiviare i dati. Se hai bisogno di salvare lo stato del programma, beh, quello è stato visto come parte della funzione del codice, così molti sviluppatori di software hanno finito per scrivere codice per organizzare i dati, salvarli, leggerli e così via.

E poi qualcuno ha capito che questo era qualcosa che è accaduto molto - che, la logica per salvare, organizzare, leggere e cercare i dati era in realtà un componente che era così comunemente usato che dovrebbe essere il proprio componente. E abbiamo database.

Negli ultimi 10-15 anni, i dipartimenti IT si sono resi conto che la logica per coreografare e / o orchestrare i processi aziendali è così comune che dovrebbe essere anche il proprio componente, che ha portato a tutti i tipi di strumenti di flusso di lavoro diversi.

Esistono 3 vantaggi principali di uno strumento per il flusso di lavoro:

1. Tempo necessario per apportare e implementare le modifiche : è possibile sviluppare e modificare la logica di un flusso di lavoro senza gli stessi rischi tecnici che si hanno con la modifica di un pezzo di codice.
2. Trasparenza : la logica aziendale in un sistema basato su BPM è immediatamente disponibile e leggibile dall'analista aziendale, mentre solo gli sviluppatori saranno in grado di leggere la logica aziendale in sistemi "basati su codice".
3. Riutilizzo di componenti tecnici : gli strumenti BPM sono spesso utilizzati in combinazione con sistemi che hanno un'architettura orientata ai servizi. Separando la logica aziendale dai componenti tecnici, in particolare per i sistemi aziendali che devono implementare centinaia o migliaia di diversi processi aziendali, è possibile riutilizzare i componenti tecnici e dedicare relativamente poco tempo allo sviluppo della logica aziendale (con un flusso di lavoro strumento).

Tuttavia, uno dei problemi più comuni che ho riscontrato con il flusso di lavoro e l'utilizzo degli strumenti BPM è che gli sviluppatori cercano ancora di "seppellire" la logica aziendale in un codice non trasparente.

Quello che vedo, sempre , è che gli sviluppatori stanno ancora cercando di aggiungere la logica di business nei modi più tecnici possibili, anziché nel modo più trasparente possibile. Questo è naturale, perché gli sviluppatori sono, per loro stessa natura, molto più a loro agio con il codice che con uno strumento di flusso di lavoro. Inoltre, più logica mantieni in modo tecnico, più avrai bisogno come sviluppatore. Sfortunatamente, questa è la cosa peggiore che uno sviluppatore possa fare a un sistema BPM perché sta sottovalutando i vantaggi principali dell'utilizzo del BPM.

Infine, la maggior parte degli strumenti di BPM non è abbastanza lontana da consentire agli analisti aziendali di sviluppare autonomamente i flussi di lavoro: tuttavia, questo è l'obiettivo. Idealmente, gli analisti aziendali svilupperebbero i flussi di lavoro / i diagrammi dei processi aziendali e gli sviluppatori lavorerebbero solo sui componenti tecnici chiamati dal motore del flusso di lavoro.

Di seguito sono riportate le mie esperienze personali con gli strumenti del flusso di lavoro, in particolare Oracle BPM Suite (10.3G e 11G). Prima di specificare, la tua domanda si concentra sugli strumenti del flusso di lavoro che consentono di modellare modelli di processi eseguibili, questi strumenti fanno parte di Business Process Management Systems (BPMS). Questo specifico processo di modellizzazione si sta sicuramente sviluppando e puoi fare riferimento ad esso come un linguaggio di programmazione visiva.

Il vantaggio principale è l' agilità di comprendere e cambiare la logica del processo

Con i modelli di processo aziendale si copre una spiegazione visiva della logica del processo e allo stesso tempo un componente integrativo eseguibile. Ciò consente un più rapido on e offboarding dei programmatori, poiché è necessario documentare meno documentazione sulle transizioni, i condizionali (gateway o regole aziendali) e il flusso di processo in generale, poiché fa parte dello sviluppo.

Inoltre, hai collegato funzionalità di reporting / monitoraggio, cosa dovresti sviluppare individualmente per ogni applicazione, che è coperto dalla maggior parte dei BPMS.

Inoltre, nella maggior parte degli ambienti di sviluppo BPM, gli adattatori di servizi sono preconfigurati (ad es. JMS, servizi Web, JDBC, ecc.), Consentendo di sviluppare soluzioni middleware più rapidamente in un'integrazione interattiva graduale, riducendo gli errori umani nella codifica.

La seguente piattaforma del flusso di lavoro offre molti vantaggi sopra menzionati: approccio basato sulla piattaforma per l'automazione dei flussi di lavoro

Il valore

La proposta di valore è che i flussi di lavoro possono essere creati o modificati rapidamente e facilmente per adattarsi alla natura mutevole di un'azienda. Una parte importante della realizzazione di questa proposta di valore è che i processi aziendali stessi sono unità di risorse nel sistema.

Flussi di lavoro come unità di risorse, significa che un processo aziendale è definito come una singola "unità". Per capire cosa intendo con questo, considera qualsiasi programma per computer scritto per un'azienda. Implementa sicuramente un processo aziendale, ma è probabile che la logica di tale processo si diffonda in una certa misura attorno al codice sorgente. Uno strumento per il flusso di lavoro dovrebbe consentire di definire il processo in un luogo ben contenuto. Potrebbe essere in un singolo file di configurazione, o estratto da un diagramma visivo, oppure potrebbe significare che il flusso di lavoro è in un singolo modulo di codice che può essere collegato, magari anche scambiato o configurato al volo.

Perché il valore potrebbe non essere realizzato

Questa proposta di valore può essere minata dalle difficoltà di coprire casi non vanilla, integrandosi con la tecnologia UI che cambia molto rapidamente, cattive pratiche come l'uso dello strumento del flusso di lavoro come un wrapper e comunque mettere la vera logica nel codice.

Una cattiva progettazione degli strumenti stessi può essere un fattore limitante. Un esempio potrebbe essere uno strumento che richiede che tutti i parametri passati tra i processi si trovino in una mappa Java, con restrizioni su quali valori si possono effettivamente inserire sulla mappa, invece di semplici parametri del vecchio metodo (sto pensando a uno dei più strumenti popolari in particolare che lo fa).

Penso che sia probabilmente giusto affermare che IBM, in quanto grande attore con un grande ecosistema tecnologico, si esibisce meglio degli altri. Se controllano anche la tecnologia dell'interfaccia utente e la tecnologia di database e SOA utilizzata in combinazione con lo strumento del flusso di lavoro, hanno maggiori possibilità di inventare un ecosistema che si integra perfettamente e crea un'opportunità per sfruttare davvero questa idea.

È sicuramente vero che lo sforzo di scrivere l'interfaccia tra uno strumento di flusso di lavoro e le altre parti di un sistema può negare completamente l'intera proposta di valore. Vale sempre la pena considerare se esiste un modo migliore di fare le cose.

La programmazione è flusso di lavoro

La verità è che la programmazione (almeno nei linguaggi imperativi) È già FLUSSO DI LAVORO. Potresti avere un codice che implementa il flusso di lavoro che ha a che fare con la gestione della tecnologia di sistema; accedere ai file ed eseguire query SQL e così via. Potresti avere un codice che implementa il flusso di lavoro aziendale; impostare lo stato di un documento e passarlo ad un revisore, ad esempio.

Riconoscere questo e progettare il codice per dividere in modo chiaro queste preoccupazioni separate è difficile da realizzare completamente, ma puoi sicuramente fare molta strada facendo proprio questo.

Sono d'accordo con te, a volte finiamo per usare questi strumenti perché qualcun altro ha deciso che fosse una buona idea, e sono troppo complessi e rendono il nostro lavoro più difficile. Non penso che sia sempre così, ha bisogno di un'attenta considerazione per decidere se ne valga la pena o no.

Non è molto chiaro quale strumento stai utilizzando. Immagino che potresti riferirti al set generale di strumenti chiamato Business Process Modeling tools. C'è una buona ragione per usare tali strumenti. Qualsiasi azienda di qualità definisce le sue funzioni in termini di processi e analista, così come gli esperti aziendali possono disegnare tali processi comodamente (fino a quando non li vincoli con gli standard ...). Puoi creare tali processi a livello concettuale senza alcuna conoscenza della programmazione web e se hai lo strumento giusto, potresti essere in grado di convertire il processo anche in un'applicazione funzionante (le persone esperte devono entrare a far parte di questa magia per entrare in produzione ovviamente). Quindi l'idea è buona.

L'obiettivo degli strumenti visivi non è solo la documentazione dei processi. L'uso degli strumenti ha lo scopo di aiutare i processi di reingegnerizzazione professionale e, a volte, eseguire simulazioni per scoprire punti in cui i processi sono meno efficienti del desiderato, in modo che possano essere predisposti piani per rimuovere i colli di bottiglia.

Esiste un modo standard che molte aziende usano oggi chiamato BPMN 2.0 (Business Process Modeling Notation). Ti consiglio di capire questa notazione se il tuo strumento la sta usando.

Il corpo di conoscenza della gestione dei processi aziendali è una risorsa famosa, che potresti voler prendere in considerazione.

Quanto sopra riguarda il lato commerciale. Il lato tecnico richiede SOA e BPEL, non sono sicuro di poter fornire consigli su quelli qui e ora però.

In semplice esempio per storia.

Età della pietra

All'inizio avevi piccole aziende di menhir in cui le persone dicevano esattamente cosa fare e lo facevano. A volte le cose vanno male e la Persona X o Y viene incolpata (non sono sicuro di chi l'abbia fatto davvero).

La prossima Internet ed e-mail sono state inventate.

La gente ora ha scritto agli altri cosa fare, e quelle persone hanno spesso avuto problemi con la loro e-mail, l'hanno letta in modo errato o hanno semplicemente eliminato un'e-mail senza mai leggerla; così spesso cose in cui non si dà la colpa a cattiva e-mail

Il flusso di lavoro si è evoluto fuori dall'amministrazione Standardizzando le azioni, alla fine le persone hanno potuto vedere in quale fase hanno interrotto un processo e, allo stesso tempo, hanno avuto una visione digitale di ciò che era stato effettivamente fatto. Questo ha funzionato bene fino a quando le persone volevano cambiare i processi standard o fino a quando una persona XY sconosciuta ha causato una richiesta di database impropria con conseguente corruzione del database, restituendo la produzione all'età della pietra.