Desafios intangíveis da implantação SOA – compartilhando experiências

Apesar da Arquitetura Orientada a Serviços não ser novidade, com inúmeros livros, artigos e materiais publicados sobre o tema, verificamos no decorrer da experiência em projetos que existe ainda uma grande discrepância na compreensão do conceito que existe por trás dessa sigla. Com frequência vemos “SOA” sendo usado para descrever uma camada com serviços de integração, muitas vezes ponto a ponto, desconsiderando totalmente a riqueza de critérios relacionados ao conceito.

Essa distância entre proposição e aplicação não é exclusividade de SOA. No desenvolvimento ágil de software, por exemplo, muitos projetistas e empresas afirmam usar SCRUM, enquanto possuem somente um grande backlog de tarefas e um quadro kamban com a lista de TO DO, DOING, DONE. Muitas vezes utilizam-se desse artifício para justificar uma documentação precária. Mas isso é um outro assunto. :)

Em projetos de integração, quando é necessária uma camada – obviamente – de integração, comumente usa-se o termo camada SOA para defini-la. Mas sem um alinhamento arquitetural apropriado, esta camada acaba se restringindo simplesmente a um aplicativo cuja função é fazer com que dois ou mais sistemas possam trocar informações entre si. Isso por si só não caracteriza SOA e não gera nenhum benefício e nem ganho tangível para a organização. Esta distorção do conceito pode causar uma grande antipatia por parte de clientes e usuários. Assim, em algumas situações, chega-se ao ponto que, basta ouvir falar em ‘SOA’, que a rejeição é certa!

Com o tempo começamos a observar que esse é, talvez, um dos maiores limitadores para que a arquitetura orientada a serviços ganhe espaço hoje nas organizações. Sem conhecer com um pouco mais de profundidade o conceito é praticamente impossível que haja aceite da utilização desse tipo de arquitetura por parte do financiador do projetos. É difícil justificar SOA do ponto de vista tempo, custo e escopo. Pensar em criar serviços que serão reutilizáveis e outros artifícios como governança nem sempre são reconhecidos quando falamos de um cenário de TI que, atualmente, trabalha sempre com curtos prazos e projetos que já começam atrasados.

Se você também se depara com essas situações no seu dia-a-dia, queremos saber o que você faz para lidar com elas. De qualquer maneira, aproveitamos pra compartilhar algumas lições aprendidas nossas:

  1. Procure compreender o conceito de SOA. Aqui no nosso blog temos alguns artigos sobre o tema (veja esse, por exemplo). Se preferir um livro, sugerimos a literatura de Thomas Erl, especialmente dois: “SOA: Concepts, Tecnology and Design” e “SOA: Principles of Service Design“.
  2. Deixe claro o que é e o que não é SOA. Quando o seu cliente chamar a camada de integração (por exemplo, ponto a ponto) de “SOA”, esclareça que isso não é uma arquitetura orientada a serviços. Se precisar justificar, lembre-se que:
  • SOA não é
  • uma tecnologia
  • uma metodologia
  • algo que se compra e que se instala
  • um webservice
  • SOA é:
  • uma filosofia arquitetural
  • baseada no conceito do uso de serviços atômicos, independentes e com baixo acoplamento

Falando de SOA, precisamos falar também de serviços. Segundo Erl, existem oito requisitos que definem uma boa implementação de serviços para que a implantação de SOA seja satisfatória. São eles:

  • Contrato de Serviço Padronizado: serviços dentro do mesmo inventário de serviços estão em conformidade com os mesmos padrões de design de contrato.
  • Serviço com Fraco Acoplamento: os contratos de serviços exigem e impõem baixo acoplamento e estão dissociados de seu ambiente e escopo.
  • Abstração de Serviço: contratos de serviços contém apenas informações essenciais. Informações sobre os serviços são limitas ao que é publicado em contratos de serviços.
  • Reutilização de Serviço: serviços contém e expressam uma lógica agnóstica e podem ser posicionados como recursos corporativos reutilizáveis.
  • Autonomia de Serviço: serviços exercem um alto nível de controle sobre o ambiente de execução.
  • Serviço statelessness: serviços minimizam o consumo de recursos, adiando a gestão da informação do estado, quando necessário.
  • Descoberta de serviço: serviços são complementados com meta dados comunicativos, onde cada um deles pode ser efetivo.
  • Modularidade de Serviço: serviços são participantes efetivos em composições (composites), independentemente do tamanho e da complexidade da composição.

Estas são algumas informações que podem ser úteis para você que também acredita nos valores de SOA.

E nós aguardamos suas experiências. :)

Vale a Pena Mapear Todos os Processos da Organização?

Um dos temas mais polêmicos quando falamos em projetos de modelagem de processos são os projetos cujo objetivo é mapear todos os processos da organização. Projetos desta natureza exigem um envolvimento global de toda a organização, pois dada a natureza dos processos de negócio, toda as áreas e papéis existentes terão que contribuir para o sucesso deste trabalho.

As empresas possuem dentro da sua operação algumas centenas de processos de negócio relevantes. O esforço para mapear tantos processos é enorme, exigindo via de regra algumas milhares de horas de trabalho.

Este esforço não se deve tanto à complexidade técnica do trabalho que tem a ser realizado, mas sim ao volume de processos que devem ser tratados. Como consequência, o projeto acaba envolvendo um número elevado de analistas de processos, muitas vezes até um número maior do que a empresa possui nos seus quadros, fazendo assim da terceirização um meio para viabilizar o trabalho.

Apesar deste número elevado de horas, este tipo de trabalho traz como resultado uma descrição em alto nível destes processos de negócio. Isso porque, se estes consultores precisassem detalhar a nível de procedimento em cada um dos processos, o esforço cresceria exponencialmente, tornando o projeto impraticável. Desta forma, o resultado de tamanho esforço é uma documentação ampla e organizada que mostra a estrutura e hierarquia de cada processo, mas sem entrar em detalhes sobre como são executados os procedimentos de suas atividades.

Com tantas pessoas envolvidas e tanto trabalho a cumprir, projetos desta natureza acabam sendo projetos caros. Não só pelas milhares de horas dos analistas de processos, mas também (e principalmente) pelo tempo demandado das áreas de negócio e por toda mobilização que acaba se fazendo necessária.

Tal mobilização acaba gerando enorme expectativa dentro da empresa: todos esperam que, ao final deste trabalho, a empresa terá um repositório com todos os seus processos e suas respectivas atividades. E é justamente na viabilidade em atender estas expectativas que está o maior desafio.

Processos de negócio são elementos vivos dentro das organizações: diariamente, surgem novas necessidades ou requisitos que exigem a sua adaptação. Quando os processos são modelados ou redesenhados de forma gradativa e planejada, a implantação de uma política de governança que garanta a atualização desta base torna-se natural. Os envolvidos nestes processos possivelmente participaram de toda uma estratégia de mobilização e discussão sobre os processos, sendo assim mais fácil obter o seu comprometimento. Contudo, quando todos os processos da organização são mapeados em poucos meses numa estratégia de documentação em série, a manutenção desta governança e a criação deste comprometimento torna-se muito mais difícil.

Desta forma, a pergunta que fica é: “Como fazer para garantir que, ao final do projeto, toda e qualquer MUDANÇA em QUALQUER PROCESSO será corretamente identificada, analisada e documentada no repositório de processos?

A viabilidade da organização em oferecer esta garantia acaba se tornando o ponto mais crítico de sucesso, uma vez que:

  1. Se a empresa não conseguir manter a base de processos atualizada, em pouco tempo existirão inúmeros processos desatualizados;
  2. Se houverem processos desatualizados, as áreas de negócio começarão a perceber que o repositório de processos não serve como base de consulta;
  3. Se o repositório não servir como repositório de consultas, ele deixará de ser utilizado.
  4. Se ele deixar de ser utilizado, toda a iniciativa cairá em descrédito.

É claro que projetos desta natureza podem trazer inúmeros benefícios, e que as empresas terminando estes projetos se conhecem muito melhor do que quando começaram. Contudo, é importante que as organizações tenham em mente que existe um limite de detalhamento que é passível de manutenção, e que elas não devem investir na criação de uma documentação que elas não conseguirão manter.

 


Conheça mais sobre o Ciclo de Vida de Processos e Projetos de BPM e desenvolva seus conhecimentos nas atividades de mapeamento, análise e redesenho de processos com nossos instrutores!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br

Respondendo a dúvidas: vale usar evento de erro em BPMN para tratar exceção de negócio?

Como já comentamos em diversos artigos deste blog, é possível representar uma mesma situação de negócio de formas diferentes com BPMN.

A seguinte questão foi levantada esta semana por um de nossos leitores, que acompanhou o diagrama logo abaixo:

“Qual a maneira correta de representar uma decisão binária (sim ou não)?
É correto utilizar o evento de erro na atividade para representar o ‘não’?
Para os 3 casos, as notificações acontecem caso o ‘caminho feliz’ não seja satisfeito. O que você me diz disso sobre a notação?
Tenho que utilizar 3 gateways?”

Este exemplo foi enviado pelo leitor para ilustrar a dúvida sobre eventos de erro na borda da tarefa.

No livro “BPMN Method & Style” 2a ed, Bruce SIlver fala o seguinte (pág 104):

“Um evento de Erro na borda de uma tarefa simplesmente representa o estado final de exceção da tarefa. O fluxo normal, a sequência de saída da tarefa, representa o seu término quando a tarefa é concluída com sucesso, e o fluxo de exceção, a sequência de saída através do evento de Erro, representa o término quando o resultado não é bem sucedido. Ele representa exatamente a mesma coisa que um gateway XOR (Exclusive data based) seguido do resultado da tarefa com fluxos de sucesso e exceção.”

De fato, ao analisarmos a especificação da notação (http://www.omg.org/spec/BPMN/2.0/), não há nenhuma restrição que indique que não seja correto utilizar este evento com esta conotação. Alguns profissionais preferem utilizar outro evento, o de Escallation, que possui semântica semelhante à do evento de Error, porém mais relacionada a uma percepção de falha relacionada ao negócio (e permite tratamento non-interrupting), reservando para o evento de erro as falhas relacionadas a exceções técnicas.

Em geral, nas modelagens que realizamos em nossos projetos, damos preferência pelo uso de gateways para verificar o resultado da tarefa (que pode ser mais do que simplesmente uma decisão binária de sim ou não). Deixamos o evento de erro na borda para tratar casos que representem efetivamente uma exceção. Um dos argumentos para esta escolha está no fato de que muitas vezes estes processos serão posteriormente automatizados em um BPMS, e para os motores de execução de processos é mais fácil realizar a validação de resultados da tarefa através desta composição.

Do ponto de vista estritamente relacionado ao uso da notação BPMN, todas as abordagens acima são permitidas.

A segunda parte da dúvida do leitor é “Tenho que utilizar 3 gateways?”

Bem, talvez não para este caso. Quem sabe podemos propor uma outra perspectiva? Uma análise do diagrama um pouco mais observadora nos faz pensar que talvez nesta modelagem as operações estejam sendo representadas em um nível de granularidade muito baixo. Será que podemos considerar que “Verificar se há período sem lançamento”, “Verificar se há RATs abertos” e “Analisar despesas” poderiam na verdade ser procedimentos de uma única tarefa? É como se a tarefa fosse “Analisar pendências e despesas” na qual a ferramenta do usuário fosse uma checklist com estas três questões.

Não seria melhor que todas as análises fossem realizadas e o colaborador recebesse como resultado não uma notificação relatando resultado apenas da primeira divergência identificada, mas uma única que já contivesse tudo o que ele precisa resolver para que sua requisição possa ser atendida? Com essa consolidação de procedimentos em uma única tarefa, não haveria mais a necessidade de três gateways, mas um. E ele poderia resolver mais do que o resultado “sim” e “não”. Que tal se os resultados fossem “aceito”, “aceito com restrições” (em que as divergências não bloqueiam a continuidade do processo) e “rejeitado”? Vale a reflexão :)

De qualquer forma, independente da opção, recomendamos sempre que a organização defina um estilo de modelagem com diretrizes de utilização da notação, que guiarão os modeladores a representarem os processos de uma forma padronizada.

 


Aprenda a utilizar todo o potencial da notação BPMN em exercícios práticos e avançados com nossos instrutores!
Confira já a agenda de cursos da iProcess Education e inscreva-se:
www.iprocesseducation.com.br

 

Os desafios da homologação de Processos Automatizados

O avanço do BPM trouxe muitos benefícios para as organizações, porém trouxe também alguns novos desafios. Para os usuários finais, isso gerou uma grande mudança cultural que, se não for corretamente encaminhada, pode colocar em risco toda a iniciativa BPM. Engana-se, porém, quem pensa que os usuários finais são os únicos que se depararam com mudanças importantes na adoção de BPM. Também a equipe de TI passou a ter novos desafios, e hoje iremos falar de um destes: a homologação da automação de processos.

A homologação de sistemas tradicionais de TI é um processo bem conhecido que envolve, em linhas gerais, a criação e a execução de roteiros de testes pelos testadores e usuários de negócio. Ao longo do tempo, uma série de ferramentas e metodologias surgiram para facilitar este processo, envolvendo desde a automação dos testes através de ferramentas específicas para este fim, até metodologias como Test Driven Development (TDD), que modificam significativamente o processo de desenvolvimento convencional.

Grande parte das homologações dos sistemas convencionais possuem em comum a existência de uma tela que deve ser homologada, ou seja, uma interface que é a “cara” do sistema para os usuários finais. Estas telas podem eventualmente ter grande complexidade, envolver múltiplos passos para execução e outros complicadores, mas o processo de homologação de um sistema convencional é normalmente bem direto: devem ser testadas todas as interações do usuário com as telas, e se certificar que o sistema está respondendo da forma esperada.

Esta forma de realizar os testes ainda continua válida no caso de homologação de automação de processos, e ainda existirão telas que deverão ser homologadas (nos casos em que usuários interagem com o processo), mas existem diferenças importantes. A principal delas diz respeito ao “coração” da automação de processos, que é o fluxo automatizado que deve ser testado. No lugar de ter apenas uma ou mais telas que precisam ser testadas, agora o principal foco dos testes passa a ser o processo automatizado em si, ou seja, a execução das tarefas seguindo o fluxo desenhado. Isto traz uma série de dificuldades bem específicas, e abaixo listamos algumas das mais importantes:

  • Um processo automatizado, muitas vezes, é iniciado por outro sistema. Nestes casos é preciso simular o disparo do processo manualmente, utilizando por exemplo ferramentas de testes de serviços (ex: SoapUI), que não são muito amigáveis para usuários finais. Nestes casos, também é preciso montar manualmente diferentes versões do que costumamos chamar de dados de entrada do processo, ou seja, os dados que serão exibidos e manipulados durante a execução do processo. Cada uma destas versões tratará de um diferente cenário previsto nos roteiros de testes.
  • Diferente de uma tela de sistema convencional, que via de regra pode ser homologada por um único usuário, um processo automatizado é composto de atividades enviadas para usuários diferentes, muitas vezes pertencentes a diferentes setores da organização. Desta forma, diversos usuários de negócio precisarão ser envolvidos no processo de homologação, cada um testando as atividades que lhe competem. Isto gera uma série de questões adicionais que precisam ser previstas em tempo de planejamento, como por exemplo, os tempos de espera que um determinado usuário poderá ter durante o dia, enquanto aguarda que os fluxos em execução atinjam o estágio em que este usuário participa do processo.
  • Embora sejam executados por diferentes papéis e eventualmente setores da organização, deve-se garantir a integridade e a perfeita execução do processo automatizado como um todo: isso exige um perfil que precisará acompanhar a execução do processo entre os diversos papéis/setores, e garantir a correta execução de todos os caminhos previstos. Envolve ações como, por exemplo, garantir a integridade dos dados sendo manipulados de uma atividade para outra, e garantir que o encaminhamento feito na atividade anterior executou o andamento correto no processo.
  • Muitas vezes, durante a execução do processo automatizado, existem integrações automáticas que não tem uma “interface” visível para os usuários. Por exemplo, são integrações que gravam e/ou obtêm informações em banco de dados e sistemas legados, usualmente via invocação de serviços. Nestes casos é preciso testar estas integrações manualmente durante a execução do processo, utilizando ferramentas mais técnicas (ex: a própria ferramenta de administração do BPMS), que no geral são pouco amigáveis para usuários finais. Nestes casos a homologação destas integrações tende a ser “delegada” para perfis mais técnicos do projeto, como analistas e testadores, visto que dificilmente um usuário de negócio terá o conhecimento ou perfil necessário para fazer estas verificações.
  • Em muitos casos, as aplicações acessadas para apoiar a realização das atividades foram construídas especificamente para serem invocadas através do processo. Logo, nestes casos é necessário ter preocupações adicionais de testes de segurança destas aplicações, como por exemplo:
    • Garantir que uma determinada aplicação só conseguirá ser acessada através da atividade específica que a invoca, e que não poderá ser acessada através de artifícios como, por exemplo, colar a url no navegador;
    • Garantir que somente os usuários dos papéis que estão atribuídos à atividade terão acesso aquela determinada instância de processo.

Como vimos, a homologação de automação de processos traz novos desafios em relação à homologação de sistemas convencionais, e precisa desta forma ser adequadamente planejada e estimada no cronograma do projeto.

BPMN: demonstrando a continuidade de processos

Uma das principais vantagens de BPMN pode também ser o seu calcanhar de aquiles: embora robusta e flexível, Business Process Modeling Notation, como diz o nome, é apenas uma notação para representar de forma padronizada aspectos lógicos de um processo de negócio. Seu objetivo não é propor uma metodologia de análise ou de documentação de processos, mas uma linguagem comum que possa ser interpretada igualmente por todos os envolvidos.

A flexibilidade da notação em permitir que um mesmo cenário de negócio possa ser modelado de formas diferentes – com alguma eventual sutil diferença em sua interpretação, possibilita que o seu uso possa ser implementado conforme for mais conveniente para a organização. Por outro lado, implica em um problema comum a todos que iniciam a sua utilização: a ausência de uma metodologia ou padrão de uso.

Por isso, é comum que profissionais que utilizam o padrão eEPC da metodologia ARIS encontrem alguma dificuldade em traçar um paralelo claro de uso entre as duas notações.

Uma das dúvidas mais comuns relacionadas à especificação de processos com uma ou outra notação está na forma como se representa a conexão entre processos.

BPMN oferece diferentes formas de se representar a continuidade de processos. Cabe aos analistas identificar qual a forma mais apropriada para atender as necessidades de documentação do seu processo – que pode (ou deve!) ser guiada por uma abordagem padrão da organização.

Neste artigo, exploramos duas formas de representar a continuidade de processos com BPMN.

 I. Acionamento por comunicação explícita entre processos

Uma das formas de se demonstrar a comunicação entre processos com BPMN é através de acionamento explícito, em que o término de um fluxo invoca diretamente o fluxo de um outro processo. Isto é feito através da diagramação em pools. Nesta notação, cada processo é disposto em uma pool. Como já vimos em artigo anterior, a comunicação entre pools acontece sempre através de message flow. Por isso, quando um processo em uma pool termina já planejando iniciar outro processo, isto precisa ser feito com eventos do tipo message.

O exemplo abaixo é o que permite um paralelo mais próximo desse comportamento com um modelo eEPC. Quando o Processo de Inscrição em Eventos termina com a identificação de que precisa iniciar o Processo de Viagens Corporativas, o evento de fim é representado como um evento de end message event, e um conector de message flow realiza a transição para a pool daquele processo. O diagrama abaixo apresenta essa representação usando uma pool black box para representar o processo de Viagens.

Neste diagrama, a continuidade do processo de Inscrição em Eventos rumo ao Processo de Viagens Corporativas é explícito através da comunicação entre os dois processos, representada pelo conector de message flow. O Processo de Viagens Corporativas está representado como uma pool black box. A sua lógica poderia estar representada em detalhes em um outro diagrama.

Se for interesse do processo visualizar mais claramente a interação entre os dois fluxos, pode-se usar a representação abaixo, que demonstra como um fluxo inicia o outro e quais atividades se seguem depois que a participação no evento foi autorizada. A diferença entre o modelo acima e o abaixo é que na representação acima o Processo de Viagens Corporativas está em uma pool black box, enquanto no diagrama abaixo está em uma pool white box.

Neste diagrama, a continuidade do processo de Inscrição em Eventos rumo ao Processo de Viagens Corporativas é explícito através da comunicação entre os dois processos, representada pelo conector de message flow. O Processo de Viagens Corporativas está representado como uma pool white box, possibilitando uma visão completa da sequênia de atividades em nível operacional.

A principal vantagem desta abordagem é que fica explícito no diagrama que um processo de negócio maior tem continuidade através dos seus processos, porém causa um certo nível de dependência entre os processos.

 II.Orquestração de Processos

Uma segunda abordagem é utilizar um diagrama de orquestração, que em um nível um pouco mais alto, fica responsável por controlar o término de um determinado processo e identificar que outro deve ser iniciado na sequência. Esta abordagem baseia-se no conceito amplo de subprocessos em BPMN.

Para BPMN, não existe uma definição de arquitetura de processos, ou de estruturação de níveis. Cada organização deve orientar como vê a empresa e definir seu próprio mapa de processos. Para BPMN, as coisas são bem mais simples. Uma atividade, em um fluxo de trabalho, pode ser:

  • Uma tarefa (um conjunto de procedimentos que compoem uma atividade realizada por uma pessoa ou grupo de pessoas, em seu menor nível de granularidade);
    ou
  • Um subprocesso, que nada mais é do que uma abstração de que naquela etapa, um conjunto definido de atividades representadas em um fluxo (um processo!) acontecerão. Quando este fluxo é concluído, então a atividade de subprocesso é encerrada e o fluxo no qual ela se encontra dá seguimento.

Assim, uma forma de demonstrar que o término de um processo dará início a um outro processo, é representá-los como subprocessos de um processo orquestrador, que dá a sequência entre eles, desta forma:

Processo de Participação em Eventos visto fim-a-fim, através da orquestração sequenciada de processos da organização.

Neste cenário, os diagramas dos processos orquestdados não precisam preocupar-se com regras que influenciarão no próximo processo (como identificar se há ou não viagem para a participação no evento). Esta lógica pode ser atribuída ao processo que faz a orquestração:

Processo de Participação em Eventos fim a fim, agora com alguma lógica de roteamento dos processos envolvidos.

Note que neste caso, os eventos de início e fim são do tipo none. Isto porque no caso de processo de Viagens, não é mais um evento de comunicação entre processos que definirá o seu início, e sim o processo orquestrador.

Nesta abordagem o processo de inscrição de eventos pode ser simplificado.

Nesta abordagem o Processo de Viagens Corporativas também pode ser simplificado, tornando-o otimizado para reuso por outros processos de negócio.

As vantagens desta abordagem são:

  • O diagrama orquestrador permite uma visão simples e clara de um processo de negócio orquestrado fim-a-fim. Isto torna-se um pouco mais difícil no cenário de acionamento por comunicação explícita, uma vez que torna-se necessário navegar de um processo para outro para chegar-se ao fim e compreender o contexto geral do processo de negócio.
  • Os processos são independentes da lógica de roteamento da orquestração, tornando-os reusáveis por outros processos de negócio (por exemplo: o processo de viagens corporativas poderia também ser usado em um processo de Execução de Projeto, Apresentação de Treinamentos, etc)
  • É possível criar condições diferentes que levem a orquestração a executar ou não um processo após a realização de outro (como foi feito para definir a execução do processo de viagens e de reembolso), e estas regras podem ser mudadas sem impactar na lógica dos processos adjacentes.

Existem também outras formas de possibilitar a representação de sequência, como uso de eventos de signal, por exemplo. Estas duas entretanto são as mais comuns e que tornam mais visível esta comunicação. O critério de definição de qual abordagem utilizar passa por uma avaliação da organização sobre como manterá todos os seus diagramas de processos reunidos e organizados, através do estabelecimento de uma arquitetura de processos.