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

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.

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

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;)

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.

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

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.

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.

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.