Simulação de processos nativa
Versus a simulação de processos ad hoc
Na primeira geração soluções de BPM, a simulação de processos foi suportada pelos simuladores de processos ad hoc baseados em máquina de estados finito primitiva que simulava a execução dos processos a serem distribuídos em um servidor de execução em separado. A boa notícia: um simulador ad hoc é relativamente simples de ser implementado. A má notícia: não reflete a verdadeira natureza do ambiente servidor executável, não pode simular a carga exatamente do teste, e não tem nenhuma visibilidade nos dados do processo, que representam uma boa metade da semântica do processo quando é utilizada uma linguagem de execução de processo como a BPEL. Quando apropriados para endereçar às necessidades dos analistas de negócio que não tem nenhum interesse na execução real dos processos que modelam, tais simuladores são totalmente inúteis ao pessoal que possui todo o ciclo de vida do processo.
Com aprendizado desta experiência, a BPM 2.0 advoga uma abordagem diferente para simulação, onde o motor de processos é usado como o simulador dos processos. De acordo com tal abordagem, os processos simulados são extraídos dos sistemas externos, quais são emulados pelo próprio motor de processos. A fim de simular um processo, o ambiente de desenvolvimento dos processos distribui automaticamente uma coleção de exemplos de processos e geram variáveis aleatórias a fim de suportar modelos da simulação tais como Monte Carlo. O motor de processos executa o conjunto de os exemplos de processos simulados e deixam o infra-estrutura do BAM agregar os resultados para serem apresentados ao analista de processos, quem tem acesso aos indicadores do desempenho do negócio (KPIs), e também as métricas do nível de desempenho do sistema.
Com esta abordagem, assegura-se de que a semântica do processo simulado possua 100% de exatidão, respeitando a semântica do processo a ser distribuído. Também, combinando indicadores do negócio com as métricas do sistema, garante que o negócio e o TI possuem uma avaliação igual dos processos distribuídos no ambiente de missão crítica em produção.
No final do dia, os simuladores de processos ad hoc serão nada além de brinquedos para os analistas do negócio, enquanto os simuladores de processos nativos são uma metrologia exata com instrumentos em que praticantes de BPM podem confiar com segurança.
Mas por que um BPMS deve suportar a simulação processo? Na postagem original do BPM 2.0, foi sugerido que o núcleo do motor de processos deveria ser usado como o simulador de processos. Ainda, não foram fornecidas muitas explanações a respeito do porque o simulador de processos é necessário em primeiro lugar. Do ponto de vista, processos do negócio podem ser visto como transações longas. Um processo de pedidos pode levar semanas para terminar o exame, quando os exemplos de um processo contratação poderiam funcionar por muitos anos. Em consequência, simular a execução de processos do negócio requer rapidez diante do tempo e os fragmentos do processo ao fazer modificações ao processo os modelos até exemplos de processos simulados entregam resultados apropriados. Diante do retorno do investimento do simulador de processos.
Assim, um simulador do processo deve também emular o comportamento externo sistemas que não podem ser envolvidos no tempo da simulação, tal como sistemas de ERP para exemplo. Isto explica porque algumas pessoas preferem o chamar de emulador de processos. Ao alimentar um modelo de processo no simulador de processos, o mais atrasado emula sistemas de terceiros e fornecendo maneiras simples para o analista de processo especificar entradas e saídas com defeito para transações remotas. Esta relação da emulação pode também incluir geração aleatória de parâmetros executando métodos de simulação, tais como, Monte Carlo.
Ao usar o núcleo do motor do processo como uma máquina virtual de processos para o simulador de processos e a plataforma de Monitoramento das Atividades do Negócio interface do usuário, a mesma infra-estrutura pode ser usada tanto pelo pessoal da área de negócio como para o pessoal de TI. A vontade anterior de simular o processo em um nível superior enquanto transações subjacentes forem acionadas por analistas de processos, e a outra de simular o processo em baixo nível com atenção especial às métricas de nível do sistema, tal como latência da transação e parâmetros de caching. Quando usado por um arquiteto de software, um simulador de processo transforma fabuloso um processo que testa e eliminar erros depurando o ambiente. Naturalmente, diferentes interfaces devem ser expostas a ambas as categorias de usuários, mas a infra-estruture pode ser a mesma.
