Qual é o valor das ferramentas de fluxo de trabalho? [fechadas]

22

Eu sou novo no desenvolvimento do Workflow e acho que não estou realmente entendendo o "cenário geral". Ou, talvez, para dizer de outra maneira, essas ferramentas não "clicam" na minha cabeça.

Parece que as empresas gostam de criar desenhos de negócios para descrever processos e, em algum momento, alguém decidiu que poderia usar uma máquina de estado como um programa para realmente controlar processos de uma linha e caixas como um diagrama. Dez anos depois, essas ferramentas são enormes, extremamente complicadas (minha empresa está atualmente brincando com o WebSphere, e eu participei de alguns treinamentos, é um monstro, até mesmo as chamadas versões "minimalistas" dessas ferramentas de fluxo de trabalho, como a Activiti. enorme e complicado, embora não tão complicado quanto o animal que é o WebSphere afetado).

Qual é o grande benefício de fazê-lo dessa maneira? Eu posso entender os diagramas simples de linhas e caixas que são úteis, mas essas coisas, até onde eu sei, são linguagens de programação visual neste momento, completas com condicionais e loops. Os programadores aqui parecem estar realizando uma quantidade significativa de trabalho na camada de linhas e caixas, o que para mim parece uma linguagem de programação visual muito ruim e básica.

Se você vai tão longe, por que não usar apenas algum tipo de linguagem de script? As pessoas jogaram o bebê fora com a água do banho? As coisas das linhas e caixas foram levadas a um nível absurdo ou simplesmente não estou entendendo o valor disso tudo?

Eu realmente gostaria de ver argumentos em defesa disso por pessoas que trabalharam com essa tecnologia e entender por que é útil. Não vejo o valor, mas reconheço que também sou novo nisso e talvez ainda não o compreenda.

user16549
fonte
1
"Ferramentas de fluxo de trabalho" nada mais são que "ferramentas de programação visual", e acho que este post no blog diz o suficiente: blog.davor.se/blog/2012/09/09/Visual-programming
Doc Brown
1
Não, ferramentas de fluxo de trabalho, são ferramentas para substituir o papel e a maneira como as pessoas trabalham de maneira padronizada. Pense em um hospital, não seria ótimo se todos os documentos oficiais seguissem as mesmas rotas, sem que algumas pessoas preferissem a rota X de documentos ou falassem / telefonassem diretamente para padronizar o trabalho, geralmente um requisito legal.
user613326
@ user613326: honestamente, você deve ler a pergunta novamente. Ele lida exatamente com o que eu escrevi - ferramentas de fluxo de trabalho para controlar e executar fluxos de trabalho, não apenas para modelá-los. Não nego os benefícios de modelar fluxos de trabalho (especialmente em formato eletrônico, em vez de usar lápis e papel), ou padronizá-los, mas ao começar a usar as ferramentas para "programação visual", não espero melhores resultados, conforme descrito acima Blog.
Doc Brown

Respostas:

8

Do ponto de vista de um desenvolvedor, você está certo ao dizer que esses ambientes "visuais" são realmente difíceis de trabalhar. Os fluxos de trabalho do SharePoint 2010, que eu uso, lançam todas as práticas recomendadas para criar bons softwares corporativos - sem testes automatizados, sem reutilização de código, software ilegível ... Qualquer coisa mais complexa do que um modelo pronto para uso pode ser difícil de manter , como você está experimentando.

Mas, do ponto de vista dos negócios, os fluxos de trabalho têm enormes benefícios - pelo menos em teoria. Para citar este white paper , a eficiência, responsabilidade, controle e facilidade de uso de um fluxo de trabalho automatizado proporcionam enormes ganhos de produtividade. Imagine o quão mais ineficiente seria um processo simples de aprovação ou integração sem essa automação. Além disso, o próprio ato de definir um fluxo de trabalho é valioso para uma organização que está tentando obter controle sobre seus processos de negócios.

O estado atual do software de fluxo de trabalho não é culpa do negócio. Eles só querem facilitar suas vidas, e os fluxos de trabalho são ótimos para isso. Eu nos culparia principalmente pelo departamento de TI:

  1. Por não ser mais transparente com os negócios sobre o quão complexo e frágil o sistema realmente é. Escondemos toda a complexidade.
  2. Por não ser capaz de "coçar a coceira" com soluções simples e intuitivas de fluxo de trabalho. Provavelmente, isso é mais contra os grandes pacotes corporativos, como SharePoint e SAP, mas eles são melhores do que as soluções personalizadas existentes
Vishal Bardoloi
fonte
2
O link ainda está morto - não há chance de ver em qual experiência do mundo real o white paper se baseia quando o recurso está ausente.
Doc Brown
7

Há apenas um benefício real, mas é enorme: Separação de Preocupações .

Portanto, em vez de a lógica de orquestração de processos ser incorporada em nosso sistema, ela se torna uma configuração externa. Um mapa, basicamente. Você pode alterá-lo (muito mais) de forma independente, pode ter vários processos, várias versões de processos, várias versões de vários processos em execução ao mesmo tempo, e isso está pronto para qualquer solução decente.


Historicamente, o conceito de SoC ganhou muitas vezes - a partir do princípio Unix "faça uma coisa, mas faça bem" e sendo aplicado repetidamente - como ter componentes de servidor dedicados como ESB, diferentes sistemas de persistência, armazenamento em cache, balanceamento de carga , monitoramento, como dividir CSS de HTML etc.

Seu processo de negócios e suas regras de fluxo geralmente são ortogonais aos seus dados, "telas" da interface do usuário ou "hierarquia" dos usuários. Portanto, faz todo o sentido desenvolvê-lo e alterá-lo separadamente dos outros aspectos do sistema. Essa foi a premissa em que o BPM apareceu no início dos anos 90.

Desde então, muitas das ferramentas e linguagens foram criadas para suportar esse conceito, sendo a mais conhecida a BPMN - uma linguagem gráfica para criar "fluxogramas" que mapeiam diretamente os processos. Enquanto as pessoas reclamam que é grande e difícil de manejar (com mais de 100 símbolos no vocabulário) e defendendo abordagens modernas como o S-BPM (tem apenas 5 símbolos básicos), a prática atual da indústria é manter o BPMN ou seus derivados, subconjuntos ou irmãos.

Você não parece satisfeito com o BPMN:

Os programadores aqui parecem estar realizando uma quantidade significativa de trabalho na camada de linhas e caixas, o que para mim parece uma linguagem de programação visual muito ruim e básica.

Mas não é tão ruim assim. Existe uma teoria por trás disso. E a versão 2.0 teve uma boa visão das deficiências da 1.0.

Se você vai tão longe, por que não usar apenas algum tipo de linguagem de script?

Paradigma imperativo e linguagens de script nem sempre são a melhor resposta. Como você provavelmente já viu em linguagens declarativas (como HTML, CSS, SQL, Drools ou internas do Nginx, Graddle e Maven, Puppet etc.), o código resultante pode ser muito menor e mais limpo do que uma versão escrita em " linguagem decente, como Java ou C ++ ".

Quanto ao seu outro ponto:

até onde eu sei, há linguagens de programação visual neste momento, completas com condicionais e loops.

você já olhou para os eventos e gatilhos ? O BPMN é um idioma e você precisa aprendê-lo antes de usá-lo, ou pelo menos se familiarizar com ele.

Sob o capô, o BPMN é XML, para que você possa editá-lo manualmente ou gerar. E você pode controlá-los por versão, porque o XML é baseado em texto. No entanto, apenas ter um XML que pode ser traduzido em fluxogramas não soa como o seu goona o ajudará, e isso é correto - escrever seu próprio analisador ou editor, pois é uma tarefa difícil e cara, com benefícios questionáveis.

Felizmente, já existem ferramentas no mercado que fazem exatamente isso.


O Activiti é gratuito e bastante popular entre desenvolvedores e proprietários de empresas, devido ao seu preço inicial ( zero ), disponibilidade de informações e humildade. O último ponto é realmente único, pois a Activi se concentra apenas no gerenciamento de seus processos de negócios, sem tentar vinculá-lo a soluções de pacotes completos. Além disso, é aberto - portanto, você só precisa conhecer Java e REST para colocá-lo em funcionamento. A desvantagem é que o lado do cliente, a integração e a lógica de aplicativos / negócios e toda a arquitetura são deixados para o desenvolvedor; portanto, se sua equipe de desenvolvimento é fraca - prepare-se para a falha. O custo total de propriedade pode ser surpreendentemente alto para uma ferramenta gratuita ;)

Do outro lado do espectro está o Pega (Pega PRPC), o rei dos sistemas BPM (de acordo com Gartner e Forester), que parece surpreendentemente bom para a sua idade. Este gigante e uma pia de cozinha é capaz de CRM, OCR e (se não me engano) recursos de reconhecimento de voz, análise preditiva, gerenciamento de regras de negócios e editor de interface do usuário WYSIWYG. Ele vem com um preço sério, no entanto. Não só custa uma fortuna, mas todo o desenvolvimento está sendo feito em um aplicativo da web, o que significa que você precisa usar o navegador, que é o IE8 (além de alguns plugins, além de hacks feios, como usar o Excel para editar tabelas de dados). Além disso, a edição em Java, Javascript ou HTML / CSS também está sendo feita no navegador da web - então diga adeus aos testes de unidade, ao destaque do código IDE, à refatoração e a todos os seus brinquedos de programação que você adorou.

Bom lado disso? você pode implementar um sistema complexo DENTRO DE SEMANAS [ PDF , consulte a página 22]. E sim, o resultado não é garantido.

IBM tem um pouco recentemente (accoring ao ritmo do tempo empresa) ter comprado Lombardi, e agora está oferecendo uma solução muito competitivo (mas , em seguida, você terá que comprar tudo ibm , you'know). Appian é um fornecedor jovem que tem idéias interessantes e feedback positivo, mas a maneira como são escritas (duas linguagens DSL extras, além da visual) simplesmente não me atrai.

Existem outros jogadores e suas soluções. A maioria deles é horrível. Como - seus olhos, cérebro e coração literalmente sangrariam quando você simplesmente os olha. Portanto, confie em sua coragem e não faça com que seus desenvolvedores e usuários o odeiem.


Nota final:

O sistema BPM é o mesmo para processos, o que o Photoshop é para imagens. Não tenha medo que seja visual. Não faça o trabalho não ser adequado para isso (lembre-se de sites criados inteiramente no Photoshop, que eram quase impossíveis de editar?). Mantenha-o simples e não cometa erros;)

c69
fonte
3

Anos atrás, antes de a maioria de nós nascer, os desenvolvedores de software precisavam escrever seu próprio código para armazenar dados. Se você precisava salvar o estado do programa, bem, isso era visto como parte da função do código, muitos desenvolvedores de software acabaram escrevendo código para organizar os dados e salvar e ler e assim por diante.

E então alguém percebeu que isso era algo que acontecia muito - que, a lógica para salvar, organizar, ler e pesquisar dados era na verdade um componente tão comumente usado que deveria ser seu próprio componente. E nós temos bancos de dados.

Nos últimos 10 a 15 anos, os departamentos de TI perceberam que a lógica para coreografar e / ou orquestrar processos de negócios é tão comum que também deve ser seu próprio componente, o que levou a todo tipo de ferramentas diferentes de fluxo de trabalho.

Existem três benefícios principais de uma ferramenta de fluxo de trabalho:

  1. Tempo necessário para fazer e implantar alterações : é possível desenvolver e alterar a lógica de um fluxo de trabalho sem os mesmos riscos técnicos que você possui ao alterar um trecho de código.
  2. Transparência : a lógica de negócios em um sistema baseado em BPM é imediatamente disponibilizada e legível pelo analista de negócios, enquanto apenas os desenvolvedores poderão ler a lógica de negócios em sistemas "baseados em código".
  3. Reutilização de componentes técnicos : As ferramentas de BPM são frequentemente usadas em conjunto com sistemas que possuem uma Arquitetura Orientada a Serviços. Ao separar a lógica de negócios dos componentes técnicos - especialmente para sistemas corporativos que precisam implementar centenas ou milhares de processos de negócios diferentes - você pode reutilizar os componentes técnicos enquanto gasta relativamente pouco tempo no desenvolvimento da lógica de negócios (com um fluxo de trabalho ferramenta).

No entanto, um dos problemas mais comuns com o fluxo de trabalho e o uso de ferramentas de BPM é que os desenvolvedores ainda tentam "enterrar" a lógica de negócios em códigos não transparentes.

O que vejo, o tempo todo , é que os desenvolvedores ainda estão tentando adicionar a lógica de negócios da maneira mais técnica possível, em vez da maneira mais transparente possível. Isso é natural, porque os desenvolvedores são, por sua própria natureza, muito mais confortáveis ​​com o código do que com uma ferramenta de fluxo de trabalho. Além disso, quanto mais lógica você mantiver de uma maneira técnica, mais será necessário como desenvolvedor. Infelizmente, essa é a pior coisa que um desenvolvedor pode fazer em um sistema BPM porque ele está diminuindo os principais benefícios do uso do BPM.

Por fim, a maioria das ferramentas de BPM não é suficiente para que os analistas de negócios possam desenvolver os próprios fluxos de trabalho: no entanto, esse é o objetivo. Idealmente, os analistas de negócios desenvolveriam os fluxos de trabalho / diagramas de processos de negócios e os desenvolvedores trabalhariam apenas nos componentes técnicos chamados pelo mecanismo de fluxo de trabalho.

Marco
fonte
1
Obrigado por sua resposta. Portanto, existem ferramentas básicas de fluxo de trabalho baseadas diretamente em gráficos e ferramentas complexas de fluxo de trabalho, que são representações visuais das linguagens de programação completas de Turing. O que eu não entendo é se você precisa de uma linguagem de programação completa de Turing ... por que não fazê-la com uma linguagem de programação de uso geral real? Se você está usando loops e condicionais, por que não está fazendo isso, digamos ... Python?
user16549
2
Como as representações visuais das linguagens de programação completas de Turing são acessíveis a um público muito maior do que os desenvolvedores, o que significa que as empresas que usam essas ferramentas precisam contratar desenvolvedores para componentes técnicos e podem permitir que especialistas em domínio façam o resto (com a ferramenta de fluxo de trabalho). Além disso, as representações visuais são imediatamente transparentes, diferente de qualquer tipo de código.
Marco
Você considerou que a verdadeira razão para os desenvolvedores implementarem a lógica de negócios no código em "linhas e caixas" não é porque "os desenvolvedores se sentem mais à vontade no código", mas que a maioria das ferramentas gráficas de fluxo de trabalho existentes é simplesmente inadequada para descrever o mundo real fluxos de trabalho de maneira executável (isso significa, com todas as exceções, tratamento de falhas, parcialmente tratamento de falhas, visualização de estado, requisitos não funcionais etc.)?
Doc Brown
@DocBrown O objetivo principal das ferramentas de fluxo de trabalho é evitar situações nas quais os desenvolvedores implementam a lógica de negócios. Idealmente, os deverlopers gastam seu tempo implementando componentes técnicos e permitem que os analistas de negócios (com a ajuda das ferramentas de fluxo de trabalho) desenvolvam e mantenham os componentes da lógica de negócios.
17556 Marco Marco
@Marco: a conclusão que tirei do que você escreveu é que as ferramentas estão longe de atender às expectativas, caso contrário, os desenvolvedores nem seriam encarregados de desenvolver a lógica do fluxo de trabalho.
Doc Brown
1

As declarações abaixo são minha experiência pessoal usando ferramentas de fluxo de trabalho, especificamente o Oracle BPM Suite (10.3G e 11G). Primeiro a especificar, sua pergunta está focada nas ferramentas de fluxo de trabalho que permitem modelar modelos de processos executáveis; essas ferramentas fazem parte do Business Process Management Systems (BPMS). Essa modelagem de processo específica está definitivamente em desenvolvimento e você pode se referir a ela como uma linguagem de programação visual.

O principal benefício é a agilidade de entender e alterar a lógica do processo

Nos modelos de processos de negócios, você cobre uma explicação visual da lógica do processo e, ao mesmo tempo, um componente integrável executável. Isso permite a entrada e a saída mais rápidas de programadores, porque menos documentação sobre transições, condicionais (Gateways ou Regras de Negócios) e fluxo de processos em geral deve ser documentada, desde a sua parte do desenvolvimento.

Além disso, você anexou os recursos de relatório / monitoramento, o que seria necessário desenvolver individualmente para cada aplicativo, coberto pela maioria dos BPMS.

Além disso, na maioria dos ambientes de desenvolvimento de BPM, os adaptadores de serviço são pré-criados (por exemplo, JMS, Web Services, JDBCs etc.), permitindo o desenvolvimento de soluções de middleware mais rapidamente em uma integração interativa passo a passo, reduzindo erros humanos na codificação.

A plataforma de fluxo de trabalho a seguir oferece muitos benefícios mencionados acima - Abordagem baseada em plataforma para automação de fluxos de trabalho

Michail Gede
fonte
0

O valor que

A proposta de valor é que os fluxos de trabalho possam ser criados ou alterados de maneira rápida e fácil para se adequar à natureza mutável de um negócio. Uma parte importante da realização dessa proposição de valor é que os próprios processos de negócios são unidades de recursos no sistema.

Fluxos de trabalho como unidades de recurso, significa que um processo de negócios é definido como uma única 'unidade'. Para entender o que quero dizer com isso, considere qualquer programa de computador escrito para uma empresa. Ele implementa um processo de negócios, com certeza, mas a lógica desse processo provavelmente se espalhará pelo código-fonte até certo ponto. Uma ferramenta de fluxo de trabalho deve permitir que o processo seja definido em um local bem contido. Pode estar em um único arquivo de configuração ou extraído de um diagrama visual, ou pode significar que o fluxo de trabalho está em um único módulo de código que pode ser conectado, talvez até trocado ou configurado em tempo real.

Por que o valor pode não ser realizado

Essa proposta de valor pode ser prejudicada pelas dificuldades de cobrir casos que não são de baunilha, integrando-se à tecnologia da interface do usuário que muda muito rapidamente, práticas ruins, como usar a ferramenta de fluxo de trabalho como apenas um invólucro e colocar a lógica real no código de qualquer maneira.

O mau design das próprias ferramentas pode ser um fator limitante. Um exemplo seria uma ferramenta que exige que todos os parâmetros passados ​​entre os processos estejam em um mapa Java, com restrições sobre os valores que você pode realmente colocar no mapa, em vez de apenas parâmetros de métodos antigos simples (estou pensando em um dos mais ferramentas populares em particular que fazem isso).

Eu acho que é provavelmente justo dizer que a IBM, como um grande player com um grande ecossistema de tecnologia, se sai melhor do que os outros. Se eles também controlarem a tecnologia da interface do usuário, a tecnologia de banco de dados e SOA usada em conjunto com a ferramenta de fluxo de trabalho, terão mais chances de criar um ecossistema que se integre perfeitamente e criará uma oportunidade de realmente usar o esta ideia.

Definitivamente, é verdade que o esforço de escrever a interface entre uma ferramenta de fluxo de trabalho e as outras partes de um sistema pode negar completamente toda a proposta de valor. Sempre vale a pena considerar se existe uma maneira melhor de fazer as coisas.

A programação é fluxo de trabalho

A verdade é que a programação (pelo menos em linguagens imperativas) JÁ É FLUXO DE TRABALHO. Você pode ter um código que implementa o fluxo de trabalho relacionado à manipulação da tecnologia do sistema; acessando arquivos e executando consultas SQL e assim por diante. Você pode ter um código que implementa o fluxo de trabalho comercial; definir o estado de um documento e passá-lo para um revisor, por exemplo.

É difícil reconhecer completamente isso e projetar seu código para dividir essas preocupações em separado, mas é possível obter um longo caminho ao fazer exatamente isso.

Eu concordo com você, às vezes acabamos usando essas ferramentas porque alguém decidiu que era uma boa ideia, e elas são muito complexas e dificultam nosso trabalho. Eu não acho que seja sempre assim, ele precisa de uma consideração cuidadosa para decidir se vale a pena ou não.

user2800708
fonte
1
"Acho que não é sempre assim" - você pode fazer backup disso por alguma experiência do mundo real? Isso seria interessante.
Doc Brown
@DocBrown Infelizmente não. Ouvi outras pessoas reivindicarem sucesso com essas ferramentas e retornos rápidos de novos processos. As únicas experiências diretas que tive deles foram de esforços enormes, pesados ​​e que consomem muito tempo que me levam a duvidar seriamente de seu valor. Resistirei a nomear o fornecedor da ferramenta desde que trabalhei para eles, mas meu sentimento era que grande parte da falha estava na própria ferramenta e na maneira como tornava a programação mais complicada.
User2800708
@DocBrown Devo acrescentar que foi sugerido o uso dessa ferramenta em meu projeto de trabalho atual. Portanto, atualmente estou tentando considerar se vale a pena comparar o nosso próprio código. Vale a pena explorar algo mais leve do que as grandes ferramentas, até agora não sei o que seria.
user2800708
A @DocBrown vale a pena notar que a pergunta atualmente possui uma recompensa afirmando "Procurando por uma resposta de fontes confiáveis ​​e / ou oficiais". À luz disso, a resposta puramente especulativa não parece particularmente útil (pergunto-me qual poderia ser a razão para votá-la) #
gnat
-2

Não está muito claro qual ferramenta você está usando. Eu acho que você pode estar se referindo ao conjunto geral de ferramentas chamadas ferramentas de modelagem de processos de negócios. Há uma boa razão para usar essas ferramentas. Qualquer empresa de qualidade define suas funções em termos de processos e o analista, assim como os especialistas em negócios, podem desenhar esses processos confortavelmente (até que você os vincule aos padrões ...). Você pode criar esses processos no nível conceitual sem nenhum conhecimento de programação na Web e, se tiver a ferramenta certa, também poderá converter o processo em um aplicativo de trabalho (pessoas experientes devem entrar em cena para que essa mágica entre em produção claro). Então a ideia é boa.

O objetivo das ferramentas visuais não é apenas a documentação dos processos. O uso das ferramentas visa ajudar a reengenharia de processos profissionais e, às vezes, executar simulações para descobrir pontos em que os processos são menos eficientes do que o desejado, para que planos sejam implementados para remover os gargalos.

Existe uma maneira padrão que muitas empresas usam atualmente chamada BPMN 2.0 (Business Process Modeling Notation). Eu recomendo que você entenda essa notação se sua ferramenta estiver sendo usada.

O Corpo de Conhecimento do Gerenciamento de Processos de Negócios é um recurso famoso, que você também pode querer considerar.

O item acima cobre o lado comercial. O lado técnico requer SOA e BPEL; não tenho certeza se posso fornecer conselhos sobre aqueles aqui e agora.

NoChance
fonte
2
OP está mencionando quais ferramentas ele tem em mente, e essas não são ferramentas de modelagem ou simulação. De fato, as ferramentas de BPM são principalmente para "criar desenhos de negócios para descrever processos", e o OP vê o valor neles. A questão é sobre ferramentas para controlar esses processos.
Doc Brown
@ DocBrown, esclarecimentos apreciados.
NoChance
1
@doc Brown - as ferramentas em questão controlam a execução dos componentes usando os vários modelos e diagramas como "código"! (E funciona tão bem quanto você esperaria - daí o arrancamento dos cabelos e o ranger de dentes do OP).
James Anderson
-2

Em um exemplo simples de história.

Idade da Pedra

No começo, você tinha pequenas empresas de menir onde as pessoas simplesmente diziam o que fazer e elas o faziam. Às vezes, as coisas dão errado, e a pessoa X ou Y é culpada (nunca sabe quem realmente fez isso).

A internet e o email seguintes foram inventados.

As pessoas agora escreviam a outras pessoas o que fazer, e essas pessoas geralmente tinham problemas com o email, liam errado ou simplesmente excluíam um email sem nunca o ler; tantas vezes coisas em que não se culpe o mau email

O fluxo de trabalho evoluiu para fora da administração Ao padronizar as ações, finalmente as pessoas puderam ver em que fase quem interrompeu um processo e, ao mesmo tempo, tiveram uma visão geral digital do que realmente havia sido feito. Isso funcionou bem até que as pessoas quisessem mudar processos padrão ou até que uma pessoa XY desconhecida causou uma solicitação inadequada do banco de dados, resultando em corrupção do banco de dados, retornando a produção à idade da pedra.

user613326
fonte
1
essa é apenas sua opinião ou você pode apoiá-la de alguma forma? Observe que a pergunta atualmente possui uma recompensa afirmando "Procurando uma resposta de fontes confiáveis ​​e / ou oficiais".
mosquito
por se basear na história, foi um exemplo hilário, mas nem todos entendem o fluxo de trabalho e o humor juntos.
user613326