Keith Swenson começou seu novo artigo no BPM.com declarando que:
Muito da confusão e dificuldade na comunidade BPM é porque algumas pessoas acham que BPM é algum tipo de engenharia de software. De fato, superficialmente parece com engenharia de software: você começa com requisitos, você determina as peças da informação que precisa ser armazenada e retornada das variáveis, você pode até ter um desenho dos relacionamentos e no final você termina com algo que pode ser instalado e executado em uma rede de computadores. Mas há uma diferença e essa diferença é a única razão pela qual BPM existe.
De acordo com Keith, engenharia de software alcançou um progresso tremendo nos últimos 50+ anos de história, incluindo programações orientada a objetos e estruturada, uma linguagem de modelagem sofisticada (UML) e uma grande quantidade de ferramentas que ajudam os engenheiros em todos os passos do desenvolvimento. Como resultado, um engenheiro de software vê "Business Process Management" simplesmente como outro exercício para converter um desenho em um programa executável:
Quando nós estamos segurando um martelo, todos os problemas à nossa volta começam a parecer pregos... Os passos de um processo de negócio são interpretados como simples passos em um programa. Quase que por reflexo, o engenheiro de software pode traduzir funções de alto nível em sequências de funções de baixo nível, com controle de fluxo, etc, em algo que pode ser finalmente convertido em linguagem de máquina, pronta para execução. Eu imagino que muitas pessoas nesta categoria sintam que BPM é apenas mais um monte de marketing sobre algo que é rotineiro no mundo da engenharia de software. Qual é o problema?
Keith tenta definir a diferença entre engenharia de software e BPM através das diferenças entre um processo de negócio e um programa típico:
Um "processo de negócio" não é um programa.Ele pode ser suportado por um programa, mas um processo de negócio é a coisa que uma organização quer que seja feita. Pode-se dizer que o processo de negócio é o objetivo do programa, mas não o program por si só. Um processo de negócio é gerenciado por uma pessoa de negócio: alguém que entenda o "negócio" e decida por uma estratégia para aquele negócio, avalie quão bem o negócio está indo e decida como mudar o processo para ir de encontro às condições de mudaça. O engenheiro de software pode gerenciar o software, mas a pessoa de negócio gerencia o procesos de negócio.
Ele continua destacando as maiores diferenças entre uma solução BPM e um programa comum:
- Uma pessoa de negócio desenha um diagrama, que é o diagrama que é executado. Ele não deve ser transformado para uma forma diferente por conveniência do engenheiro de software. Ele não deve ser transformado para uma forma diferente de execução... Esta transformação serve o propósito da ótima execução, particularmente em máquinas que são limitadas em capacidade de processamento. Alguns processos de negócio ainda precisam disso, mas a grande maioria não serão prejudicados com a performance da CPU.
- Os relatórios históricos e analíticos precisam seguir o diagrama original para ajudar ao usuário de negócio avaliar a performance da organização, não para o programador dizer quão bem o programa está rodando.
- Em um sistema de software, o usuário raramente precisa saber como o programa está estruturado por dentro, mas um processo de negócio não é um programa nesse sentido. O processo deve ser visível, mesmo como o programa que o suporta executa. A pessoa que está envolvida no processo deve ser capaz de entender em qual passo de um processo você está, qual será o próximo passo e quais foram os últimos passos. Isso é a maior diferença entre BPM e engenharia de software.
De acordo com Keith, a maior fonte de confusão e desentendimento é o fato de que frequentemente o design e desenvolvimento do BPM é feito por engenheiros de software:
Infelizmente, muitas pessoas que estudam sistemas BPM, frequentemente vem de uma base de engenharia de software e automaticamente assumem que BPM deve ter algumas características padrão de software. Engenheiros de software vêem o sistema como uma forma de enviar, receber e transformar informação e eles são treinados para reduzir os problemas de negócio em algo que pode ser executado nesses termos. Pessoas de negócio não focam em enviar e receber bytes, mas ao contrário, em responsabilidade e comprometimento. Isso é uma forma diferente de ver um processo de negócio. O efeito desta grande diferença é enorme. Ao tentar incluir tudas as características de engenharia de software com as as características do BPM (pessoa de negócio), o resultado pode ser algo que não é útil para ninguém. Há pessoas hoje que ainda acreditam que BPEL é a última palavra para implementar processos de negócio. BPEL somente fornece uma forma de enviar, receber e transformar... estes são requisitos de engenharia de software, não de negócios. Um engenheiro de software dirá que com essas primitivas você pode implementar qualquer coisa, provavelmente até mesmo uma planílha, mas foge completamente ao motivo de se ter uma planílha e BPM em primeiro lugar: porque eles não são engenharia de software.
Keith conclui seu artigo avaliando as atividades atuais do OMG BPMN 2.0:
Há uma grande discussão na lista de email da OMG sobre como BPMN é apenas um outro dialeto da Unified Modeling Language (UML), o padrão de diagramação preferido pelos engenheiros de software. De fato, um engenheiro de software pode olhar para BPMN e ver algo útil para a engeharia de software. Lembre que OMG antes de mais nada é uma organização de e por engenharia de software e não surpreende que muitos membros da OMG chegariam a esta conclusão. Muitos deles até mesmo podem imaginar que UML é útil para todas as disciplinas. Tornar BPMN um dialeto da UML seria muito conveniente para a prática de engenharia de software de reduzir um diagrama a um prorama executável.
BPMN serve para pessoas de negócio para expressar como as pessoas interagem em uma configuração de negócio. Há muitos dentro da OMG que entendem isso também e eu espero, para o nosso bem, que eles não sejam derrubados por aqueles que vêem todos os problemas como problema de engenharia de software. BPMN não existe para a conveniência dos engenheiros de software, porque BPM não é engenharia de software.
Há definitivamente muita confusão na indústria, sobre o relacionamento entre engenharia de software e BPM. São duas disciplinas muito diferentes, mas relacionadas. De um lado, é bem possível desenhar e implementar processos de negócio sem qualquer automação e por outro lado, automação de processos de negócio definitivamente requer uma quantidade significativa de engenharia de software envolvida.