Quando utilizzare i motori del flusso di lavoro?

Ho lavorato in passato su alcuni dei motori del flusso di lavoro come programmatore, ma non ho mai avuto chiarezza sul perché abbiamo scelto i motori del flusso di lavoro al primo posto. E come programmatore so che ci sono almeno 100 modi per fare qualsiasi cosa quando scrivi un codice, ma solo alcuni dei modi sono i migliori!

Non capisco ancora quali casi d'uso siano meglio risolti dai motori del flusso di lavoro (o meglio dal loro concetto) piuttosto che progettare una buona applicazione abilitata alla DI. Sto cercando tutte le caratteristiche generali dei casi d'uso neutrali del dominio, in cui i motori del flusso di lavoro sono una delle migliori opzioni.

Quindi la mia domanda è: quali sono le caratteristiche generali di un requisito che può essere preso come segnale per optare per un buon motore di flusso di lavoro e codificarlo?

Un motore di flusso di lavoro è utile quando è necessario passare dall'inizio alla fine, ma ci sono molti percorsi / logiche / regole diverse per arrivarci.

Ad esempio, diciamo che scrivo un programma che pubblica contenuti. Quindi, nel mio caso, la pubblicazione passa attraverso un processo di revisione, legale e quindi l'approvazione finale. Scrivo il programma implementando la mia logica di processo e passaggi. Ora funziona alla grande per me e la mia compagnia. Quindi, decido che gli altri dovrebbero usare il mio programma.

Sfortunatamente, non tutti pubblicano contenuti utilizzando lo stesso processo, quindi invece di scrivere processi separati per ogni caso diverso, implementeremmo un processo di flusso di lavoro in modo che il programma sia flessibile per soddisfare tutti. Indipendentemente dal numero di passaggi, regole o logica tra questi due punti, il risultato è lo stesso.

Quindi, se hai processi che sono variabili dall'inizio alla fine, usa un flusso di lavoro. Se lo stesso processo può essere utilizzato da tutti, non è necessario un flusso di lavoro.

So che hai chiesto casi d'uso, ma è più facile elencare i vantaggi che immaginare tutti i possibili casi d'uso. I vantaggi ovviamente dipendono dal motore e dalla lingua che stai confrontando, ma in generale:

1. Mantenere le regole come dati anziché come codice significa che non è necessario ricompilare, quindi è possibile verificare rapidamente le modifiche, modificarle in fase di esecuzione, ecc. Non è molto vantaggioso se non è necessario ricompilare in primo luogo, comunque.

2. È più probabile che gli utenti modifichino le regole. Possono potenzialmente armeggiare con loro in modo interattivo in modi che non sono fattibili quando un programmatore scrive codice per loro.

3. Mantenere le regole come dati consente agli strumenti di essere scritti per visualizzare e modificare i dati.

4. Mantenere le regole come dati consente una meta-programmazione più facilmente: è possibile scrivere codice per analizzare i dati e inserirne di più in modo complesso, il che sarebbe molto difficile per il codice.

Tutte queste cose sono possibili da fare direttamente con il codice (ad es. Scrivere un parser C # per trovare tutte le regole di un certo tipo e generare codice per più regole, inserirlo dinamicamente in un assembly in modo da consentire lo scarico degli assembly, scrivere strumenti per gli utenti possono farlo anche usando il tuo visualizzatore ed editor) ma può essere molto più difficile a seconda del tuo linguaggio (i programmatori che usano un Lisp potrebbero riferirsi alle voci 1-4 come "programmazione").

IMHO l'UNICO caso in cui dovresti usare questo genere di cose è quando può essere configurato da utenti meno preziosi. Se riesci a risolvere il tuo problema dando loro uno strumento, tornando a lavorare su qualcos'altro più importante, allora usane uno.

Se hai ancora bisogno di configurarlo per loro, immagino che potresti pensare a 10 modi diversi per ottenere lo stesso risultato con uno strumento che conosci e che sarà molto più facile da supportare e personalizzare.

Sembra una vecchia domanda, ma affiora numerose volte in natura. Sono d'accordo con la risposta di Jon . Ho trovato i motori del flusso di lavoro altamente produttivi nei seguenti scenari:

1. Esiste un processo aziendale sottostante che stai tentando di rappresentare / implementare attraverso il tuo software.
2. Esiste una singola entità aziendale (forse composita) su cui si lavora in tutte o in alcune fasi del processo. Nell'esempio fornito da Jon, questa entità o elemento del flusso di lavoro sarebbe contenuto o un articolo. Considera il tracciamento dei bug come un altro esempio di flusso di lavoro, una transizione dei bug tra vari stati, basata su un'azione intrapresa da un utente.
3. Utilizzare i flussi di lavoro per modellare i processi, solo se si prevede che il processo aziendale cambi, per cambiamento intendo la sequenza o l'azione eseguita a seguito di un'azione o transizione dell'utente.

Sii molto attento e critico per vedere se il tuo dominio / requisiti problematici ha un processo aziendale, non cercare di "adattarlo" a un flusso di lavoro.

Ho un paio di linee guida che uso per suggerire i motori del flusso di lavoro.

1) Quando gli analisti aziendali non hanno un background di codifica ma possono disegnare diagrammi.

I moderni motori del flusso di lavoro utilizzano la notazione di modellazione dei processi aziendali o le versioni meno capaci disponibili in SharePoint e sistemi simili. Ciò consente ai membri del team tecnicamente competenti ma con problemi di codifica di progettare e sviluppare molti flussi di lavoro.

2) Quando è necessario monitorare l'avanzamento del lavoro, eseguire escalation, alternare tra processi controllati dal computer e processi controllati dall'uomo.

Il monitoraggio e l'autoreferenzialità sono le caratteristiche distintive dei moderni motori del flusso di lavoro.

Dal punto di vista del business delle risorse umane, i motori del flusso di lavoro sono molto importanti.

1. Forniscono un processo strutturato, anche se è sempre lo stesso.

2. Forniscono trasparenza

   • Chi ha richiesto la modifica,
   • Quando è stato richiesto,
   • Chi ha approvato ecc.

   Questa trasparenza aiuta a guidare il processo e promuove la proprietà.

Supponendo che i moduli siano integrati e intelligenti, a supporto della logica aziendale, ha anche un effetto drammatico sulla cronologia, l'efficienza di elaborazione e la qualità dei dati. Anche la sicurezza è una considerazione e contenere informazioni sensibili in un sistema sicuro è molto preferibile avere moduli cartacei in attesa di essere firmati. È anche molto più mobile. Dopo una recente implementazione, un manager mi ha detto che gli ha risparmiato molta seccatura nel ricevere cose che gli venivano inviate per la firma mentre viaggiava molto.

A nome delle risorse umane: viva il flusso di lavoro !!!