BPM Na Veia

Service Oriented Reference Architecture – Parte 1 ½

“Qual a diferença de SOA para algo que já se fala ha muito tempo: programação (e arquitetura de aplicações) orientada a objetos (e/ou componentes)?” Esse (primeiro) comentário no nosso blog (Obrigado Mário!) me levou a entender que a visão sobre o que é uma arquitetura orientada a serviço (SOA) tem ainda não está consolidada, nem entre clientes, nem entre fornecedores. Para resolver isso resolvi criar um item 1 ½ para tentar explicar melhor esse tópico.

Quando desenvolvi meu primeiro sistema (num Apple II+, no bom e velho BASIC) tive muito trabalho, como todos que trabalharam com essa linguagem, para controlar uma quantidade imensa de GOTO’s e JUMP’s dentro do código. E não passava de um mero sistema de automação de oficina eletrônica (daquela época que as TVs apresentavam alguns problemas por ano). Mas foi exatamente assim que surgiu a programação: SEQUENCIAL. Um bloco único de código de executava do início ao fim a finalidade do programa.

Nessa época, a cadeia de valor das empresas ainda era muito restrita. Mesmo os mainframes dessa época trabalhavam com sistemas focados em uma única área: folha de pagamento, controle de estoque, etc.

Logo depois inventaram uma revolução: functions ou procedures. A programação PROCEDURAL foi um grande marco na computação: a possibilidade de reutilizar funções dentro do mesmo programa era algo incrível. Não precisávamos mais gerenciar aqueles laços de GOTO que eram responsáveis por boa parte do bugs.

Mesmo assim, com o aumento da complexidade dos sistemas, a quantidade de linhas de código levou à conclusão que seria mais fácil arrumar uma forma de deixar essas funções em módulos (vários arquivos fonte) que, em tempo de compilação, seriam resolvidos. Chegávamos ao estado da arte (na época): a programação MODULAR.

Esta ainda começou a evoluir de forma espantosa: primeiro as bibliotecas de funções de vinculação estática (em tempo de compilação, as .LIB) e depois bibliotecas de vinculação dinâmica (as conhecedidas .DLL). Naquela época não haveria mais para onde evoluir.

Neste momento da história as cadeias de valor das empresas começaram a ficar mais complexas, demandando, além de sistemas mais complexos, maior agilidade por parte do analistas e desenvolvedores.

Foi no início dos anos 90 quando apareceu um conceito que quebraria alguns paradigmas: A PROGRAMAÇÃO ORIENTADA A OBJETOS. Este era um conceito dos anos 60 que ainda não tinha tido espaço para implementação. A POO tinha como enfoque unidades de programação discretas (objetos) ao invés da programação estruturada normal. O foco da programação estruturada sempre foi a estrutura (óbvio) enquanto a POO se preocupava mais com o comportamento e com os dados. Fazendo um comparativo com a estória da evolução da eletrônica, chegávamos na era dos circuitos integrados: unidades específicas de processamento com comportamento definido, entradas específicas e saídas dependentes dos estados das entradas.

A POO já possibilitava um grande aumento da produtividade e reuso de software mas, para nossa infelicidade (ou felicidade) agora tínhamos a necessidade de fazer com que programas distintos conversassem entre si.

Aqui as cadeias de valor começaram a demandar maior troca de dados entre os diversos sistemas para agilizar os processos de negócios e tornando as empresas mais competitivas.

Entra em cena neste momento o EAI (Enterprise Application Integration). Um conjuntos de princípios arquiteturais e ferramentas (ou middleware) para promover a comunicação entre aplicativos distintos. Dentre as ferramentas destacam-se os MOM (messaging oriented middleware), camadas de software que se encarregavam das complexidades de transmitir uma mensagem da origem ao destino. Inicialmente a infra-estrutura de EIA trabalhava com integração ponto-a-ponto, o que não representava grande problema quando trabalhávamos com um número pequeno de entidades, como na figura 1 abaixo.

O sistemas de estoque tem duas interfaces: uma para o sistema de folha de pagamento (I1) e outra para o sistema de contabilidade (I6), os outros dois sistemas têm também duas interfaces cada. O número total de interfaces nesse cenário é de (somente) seis!

O problema aconteceu quando um grande número de aplicações com necessidades de intercomunicação começou a aparecer. O número de interfaces começou a ficar inviável.

A grande preocupação era o crescimento exponencial do número de interfaces. Para n aplicações, são necessárias n*(n-1) interfaces. Isso signifca que para integrar 5 sistemas, conforme a figura 2, são necessárias 5*(4)= 20 interfaces. Já para integrar 20 sistemas (o que é uma quantidade razoável de sistemas para uma empresa de médio/grande porte) são necessárias 380 interfaces!

Mais uma vez, as mentes brilhantes da computação resolveram essa complexidade de uma forma espetacular: a criação de um modelo HUB AND SPOKE. A figura 3 representa esse modelo onde, um componentes central de middleware é responsável pela transformação, mediação e roteamento das mensagens.

Esta solução prometia durar muito tempo. E durou! Os conhecidos integradores ou brokers desempenharam um papel fundamental por muitos anos, integrando sistemas de todos os tipos.

A diversidade de tecnologias suportando as cadeias de valor em conjunto com a necessidade de interconexões extra-empresa levaram à criação de um modelo mais flexível de integração entre aplicações: a CORBA.

Uma outra tecnologia importante começou a nascer: a CORBA (Common Object Request Broker Architecture). Corba é a arquitetura padrão criada pelo Object Management Group (OMG) para simplificar a troca de dados entre sistemas distribuídos heterogêneos. Em face da diversidade de hardware e software encontradas, a CORBA atuava de modo que os objetos (componentes dos softwares) pudessem se comunicar de forma transparente ao usuário, e o mais transparente possível também para o desenvolvedor.

A CORBA definia o ORB (Object Request Broker) como um módulo intermediário entre cliente e objeto, sendo responsável em aceitar a requisição do cliente, enviá-la para o objeto competente e, assim que disponível a resposta, entregá-la para o cliente. Definia também a IDL (Interface Definition Language), uma linguagem baseada em C++ que não possuia algoritmos nem variáveis, ou seja, puramente declarativa independente da linguagem de programação utilizada para acessá-la. Possibilitava a interoperabilidade entre os diversos sistemas, visto a separação que é definida entre interface e execução. A interface de cada objeto é definida de forma bastante específica, enquanto sua execução (código fonte e dados) permanece oculta para o resto do sistema.

Com o advento da linguagem Java os conceitos de CORBA ainda foram utilizados para implementar a invocação remota de métodos (RMI – remote method interface). RMI eram formas de invocar componentes Java existentes em outras máquinas. A grande vantagem era que a RMI desonerava o programador da complexidade dessa programação.

A figura 4 demonstra a facilidade que o modelo de invocação remota trouxe. O programador (usuário) se preocupada basicamente com o desenvolvimento da aplicação enquanto a infra-estrutura CORBA e a ferramenta de desenvolvimento se encarregavam da comunicação.

O modelo RMI foi amplamente implementado quando a linguagem Java foi atualizada para sua versão corporativa: J2EE (Java 2 Enterprise Edition). A invocação de EJB (Enterprise Java Beans) sempre utilizou uma infra-estrutura de RMI. Os EJB eram abtrações de estados (session beans) e de dados (entity beans).

Quando a cadeia de valor das empresas chegou à internet a linguagem JAVA ganhou importância com sua afinidade com esse ambiente. Especialmente quando a internet deixou de ser uma vitrine e começou a ser efetivamente um canal de negócios.

A arquitetura J2EE também implementou diversos mecanismos de conexão a ambientes não-java como o JCA (Java Connector Architecture) e o JMS (Java Messaging Services) e esses, até então, estão suprindo as necessidades de integração da plataforma Java.

Entretanto, alguns fatores de negócio estão ganhando importância, demandando uma nova visão de tecnologia:

• Necessidades de redução de custos com manutenção de aplicações;

• Demandas de negócio cada vez mais complexas o que gerando aplicações igualmente complexas;

• Competitividade obrigando as empresas a reduzir o time-to-market de seus produtos e serviços;

• Necessidades regulatórias que demandam acesso mais complexo às infomações.

Para atender a esses novos princípios foi concebida a arquitetura orientada a serviços – SOA.

João Luiz Pereira Junior

EXTRA! EXTRA! Acabou de sair...

Caros amigos do BPM na veia, vejam só o que achei hoje. A OMG (Object Management Group), consórcio que define uma série de padrões da indústria de TI, acaba de lançar um programa de certificação em conceitos de BPM chamado "OCEB program" (OMG-Certified Expert in BPM).

Isso é interessante pois mostra que BPM vai muito além de simplesmente ferramentas de diversos fornecedores mas que, na verdade, trata-se de uma disciplina que envolve, entre várias outras coisas, ferramental de TI.

Para maiores informações, veja aqui.

Luiz Phelipe Souza

BPM é Responsabilidade de Todos

Soa estranho esse título, não é? Quando escrevi, lembrei das campanhas de combate à dengue ("Combater o mosquito é dever de todos")... rsrsrs...

Pensando no tema deste blog, O que eu quero dizer com isso é que o conceito BPM é muito mais que, simplesmente, um novo jargão do pessoal de TI e que, invariavelmente, essa turma gosta de usar em conversas.

Vamos entender um pouco mais o desenho abaixo, sem pensar muito em tecnologia ou ferramentas:

CICLO DE VIDA SOA

Supondo que a "porta de entrada" para a implantação de um processo de negócio - e esquecendo que a palavra implementação pode estar associada a desenvolvimento de sistemas - temos as etapas de definição do processo (modelagem), implementação do processo "na cabeça das pessoas" (assembly), execução do processo (deploy) e acompanhamento (monitor).

Agora, vamos lembrar um pouco de um dos 1os posts deste blog (veja aqui). Lembro que comentei que BPM são procedimentos que sempre existiram nas organizações, bem ou mal seguidos, mas muito antes de pensarmos em computadores ou coisa parecida. É natural, portanto, já falarmos em envolvimento de alguém responsável pelo processo diretamente no projeto e não, simplesmente, tratá-lo como um "usuário" ou "cliente" do projeto (coisa extremamente comum dos projetos de TI).

O que tenho visto em alguns lugares que discutem BPM é um certo "descaso" com a etapa MODELAGEM, principalmente pela turma de TI. Comentários do tipo "o pessoal da minha empresa é muito imaturo para isso" ou "isso não se aplica muito para o meu caso" são frases que tenho escutado.

Entendendo que as etapas de ASSEMBLY e DEPLOY são de responsabilidade fundamental de TI (e não discuto muito sobre isso) sobraram as etapas de MONITORAçÃO e MODELAGEM, que citei no parágrafo acima. Em MONITORAçÃo, normalmente pensamos no gran-finale de um ciclo  de desenvolvimento de um processo, que é a visualização e análise de quão bem ou quão mal anda o mesmo.

Em MODELAGEM que está o "X" da questão. É neste ponto que se define como o processo anda atualmente, como ele pode ser executado, que melhorias podemos ganhar com a mudança (pensando em funcionalidades de simulação) e, mais, como poderemos "medir" o processo em execução, isto é, como veremos, na etapa de MONITORAÇÃO, se as melhorias que estamos propondo em tempo de modelagem serão, de fato, confirmadas em produção. Os famosos KPIs (indicadores chave de performance) DEVEM ser definidos neste ponto. E por quem? Pelo grupo de TI, que cuida de Web Services, EJBs, ESBs (e outros jargões) ou pelo "usuário imaturo em tecnologia" mas que sabe, de fato, os indicadores que poderão medir a saúde da empresa?

Portanto, o que quero dizer é que um projeto de BPM para ser bem sucedido é FUNDAMENTAL (coloquei maiúsculo de propósito) que os gestores do processos estejam envolvidos deste o 1o minuto do projeto e, mais, sejam parte integrante do time, durante todas as fases, principalmente, da etapa de modelagem. Eu disse parte integrante e não "cliente" do projeto.

Obviamente, há uma série de outros fatores que facilitam (ou dificultam) uma boa implementação. Nunca vamos esquecer, por exemplo, de controles de change management (gestão de mudanças) que vai promover o projeto junto à organização, mostrar os benefícios que a solução irá agregar ao negócio e treinar os envolvidos.

Você consegue lembrar de algum projeto que naufragou por conta de fatores alheios aos aspectos tecnológicos? Não foi difícil lembrar, foi?

Luiz Phelipe Souza

Portal de Processos: "Um Shopping de Tarefas"

Quando as empresas começam a implementar uma gerencia de processos internamente, verifica-se uma quantidade muito grande de processos que possuem intervenção humana. Esses processos podem ser desde uma simples aprovação até uma tarefa de preenchimento de formulários complexos, conforme citei em um post anterior. Já verifiquei muitas empresas implementando aplicações web stand alone, para implementação dessas interações humanas. Todavia com o crescimento da implementação de processos com interações humanas, fica inviável para o usuário final ficar acessando diversas aplicações webs, com urls diferentes, muitas vezes com logins diferentes, fora todo o problema de acompanhamento dos processos iniciados. Sem contar que maioria das vezes se faz necessário o usuário final utilizar outras aplicações / ferramentas para a realização eficiente da tarefa (por exemplo: email, ERP, entre outros).

Exatamente por essa necessidade, é necessário a implementação de um ambiente de trabalho único, o que chamamos no mercado de Portal de Processos.

O Portal de Processos tem como característica ser o único ponto de acesso do usuário final, uma analogia que nos auxilia a entender o portal de processos seria com um shopping. Similarmente ao shopping, o portal de processos permite você acessar todos os serviços necessários em um ponto único, utilizando serviços padronizados (no caso do shopping: estacionamente, refrigeração, alimentação; no caso do portal: busca, autenticação, ferramentas de colaboração) e de fácil navegação.

Um dos serviços principais de um portal de processos, seria permitir o usuário final acessar/executar suas tarefas pendentes, gerenciar e monitorar os processos instanciados, consultar base de processos modelados, iniciar a execução de um novo processo, isso tudo agregado com outras aplicações que auxiliem a execução de cada tarefas, tais como ferramentas de colaboração, biblioteca de documentos, Sistemas de ERP, CRM, BI, ECM, e até mesmo sistemas legados. Como característica fundamental desse ambiente de trabalho unificado, é personalização das informações e serviços apresentados, de acordo com o perfil do usuário (por exemplo apresentar notícias e sistemas de acordo com o cargo e departamento do usuário final). Outra característica muito presente nesses portais é permitir que o usuário final customize seu ambiente de acordo com seu interesse, podendo definir o que ele quer vê e aonde. Um dos requisitos que tenho visto bastante nos clientes, é possibilitar que tarefas com interações humanas, sejam acessadas não apenas na Web, como também dentro das ferramentas que os usuários utilizam no seu dia-dia, tais como nas ferramentas de email e de instant Message, além de ser possível de acessar em dispositivos móveis, e também em equipamentos desconectados da rede corporativa (acesso offline).

Em resumo, características de uma ferramenta de portal de processos internos, é fundamental para que se consiga diminuir o tempo de execução de processos, possibilitando o usuário final executar tarefas de forma mais produtiva e possibilitando ele ter acesso aos dados necessário para execução eficiente do processo, permitindo assim uma melhor otimização dos recursos humanos de uma corporação.

Rafael de Oliveira Osório

Demo

Esse post é um pouco diferente dos demais, não pensem que eu vá falar de cultos religiosos ou coisas do tipo, como o título sugere, na realidade é muito mais uma recomendação de um site que descobri navegando no site de demonstrações (por isso o título demo) da IBM.

No site abaixo, vocês iram encontrar 3 videos que demonstram o valor de negócio agregado do uso de BPM enabled by SOA dentro do mundo corporativo.  Como acredito que uma imagem vale mais do que mil palavras, acredito que os videos iram concretizar os conceitos descritos nos outros posts anteriores.

Segue o site: Business Process Management Demos Enabled by SOA

Rafael Osório

O que considerar numa suite de BPM?

Escrevi em outro post sobre o conceito principal em cima da sigla BPM e como outra sigla, SOA, complementa e facilita a implementação de soluções de gestão de processos (Leia Aqui).

Neste tópico, vou comentar sobre as principais funcionalidades exigidas pelo mercado de TI para as suítes de BPM e que já estão disponíveis pelos principais players do mercado.

MODELAGEM & SIMULAÇÃO : Espera-se com esta funcionalidade a capacidade de documentar processos de forma rápida e imediata, isto é, sem grandes conhecimentos da ferramenta, é esperado que o usuário seja capaz de começar o desenho do seu processo. Além disso, um requisito mandatório atualmente é a capacidade de simulação, ou seja, conseguir "alimentar" seu processo com informações de custos, prazos e disponibilidade de recursos para identificar, em tempo de projeto, onde podem estar os principais "gargalos" ou pontos de melhoria que justifiquem uma re-engenharia do processo. Por fim, mas não menos importante, é a possibilidade de exportar o resultado do trabalho de modelagem para uso pela equipe de TI, responsável final para colocar aquele processo automatizado e em execução. Com isso, começamos a ter o grupo de negócios e processos trabalhando efetivamente no desenvolvimento de uma solução.

AMBIENTE COLABORATIVO: Entende-se por este conceito a possibilidade de extender o seu ambiente de desenvolvimento e os produtos desenvolvidos para uma comunidade maior de usuários que podem, com isso, colaborar na solução final. Algumas funcionalidades interessantes são a definição de um repositório comum de projetos já construídos ou em desenvolvimento e foruns de discussão sobre os principais objetivos do projeto. Pensando já na execução de um processo de negócios, é natural que existam intervenções humanas ao longo do mesmo(por exemplo, aprovações). Há que se considerar, portanto, que no ambiente de desenvolvimento, as ferramentas incluam facilidades para desenhar as interfaces com o usuário e, além disso, tenham mecanismos para controles de execução de tarefas humanas, como possibilidades de "escalar" outro funcionário em caso de demora excessiva na execução da tarefa ou mesmo a possibilidade de delegações temporárias de papéis.

MONITORAÇÃO DE PROCESSOS: Já bastante comentado em outro post (Leia Aqui), esta funcionalidade tem por objetivo mostrar aos gestores dos processos como andam seus "filhos", isto é, quão bem ou quão mal os processos rodam na organização. Indicadores de desempenho (KPIs), gráficos consolidados e visões operacionais estão como os principais desejos dos gestores que, normalmente, irão patrocinar um projeto de BPM para conseguir a tão sonhada "gestão on-line e real-time".

PROCESSOS DINÂMICOS & APLICAÇÕES COMPOSTAS : Tem sido comum, em tempo de projetos, os requerimentos de dinamicidade e flexibilidade de manutenção do processo, ou seja, a capacidade de manter meu processo sem tirá-lo do ar ou, pelo menos, minimizar ao máximo o downtime. Afinal, este é um grande apelo do "BPM enabled by SOA". Soluções de mercado atuais incluem a possibilidade de se criar um processo customizado e que pode ser mantido a partir de políticas de execução do mesmo, isto é, baseado nas informações do cliente que invocou (se é um cliente preferencial ou não), de onde ele veio (se por um portal, por URA, por atendente, etc) e/ou dos dados contidos na invocação (se é um pedido de um novo produto algo já pedido) chegar a uma granularidade bastante particular do processo que inclui sistemas, grupos de atendimentos distintos e qualidades de serviços completamente distintos.

PROCESSAMENTO DE EVENTOS DE NEGÓCIOS : Não somente a monitoração dos processos está na lista de anseios de clientes de BPM. A capacidade de se identificar padrões de execução e/ou comportamento do cliente final e, com isso, tomar alguma decisão automática tem sido uma funcionalidade bastante comentada. O exemplo mais simples para ilustrar é o caso de um usuário de telefone celular que tem um registro de ligação no Rio de Janeiro e, quinze minutos depois, consta um registro de ligação a partir de Fortaleza. Bom, neste cenário, ficou bastante evidente uma fraude na conta daquele cliente. Com alguma ferramenta que permita extrair eventos de negócios do processo em execução, montar padrões de desvio e invocar ações automáticas, consegue-se implementar este tipo de requerimento, citado no exemplo.

EXECUÇÃO DO PROCESSO: Neste ponto, fala-se principalmente na capacidade de orquestrar e montar o processo (a partir de serviços automáticos ou humanos) além do próprio ambiente operacional que irá ser executado o processo. Em tempo de desenvolvimento, é extremamente importante que se consiga, antes de mais nada, importar algum artefato proveniente da etapa de modelagem (comentei isso acima na perspectiva do analista de processos). Mais: atualmente, o mercado de TI tem desenvolvido alguns padrões de linguagens e conceitos para a implementação do "BPM enabled by SOA". Considero como principais o BPEL, que é uma representação para a execução de um processo e invocações para serviços existentes (automáticos ou humanos) e o SCA (Service Component Architecture) que é uma representação dos processos e suas dependências para execução. Neste caso, temos o "SOA na prática". Vemos em diagramas o processo montado, suas interdependências e, em caso de manutenção para troca de serviços, simplesmente nos limitamos a "trocar caixinhas". Tão simples quanto isso ! Sobre o ambiente operacional... Bom, em primeiro lugar, não se espera de um ambiente que irá rodar, por exemplo, seus processos de venda algo sem grandes contingências, alta disponibilidade, segurança e tudo mais que se espera de um servidor de produção. Portanto, em suas iniciativas de BPM, não se esqueça de verificar com seu fornecedor em que sistemas operacionais o tal servidor rodará além da capacidade de escalabilidade e alta disponibilidade.

REPOSITÓRIO DE SERVIÇOS: Esse é um requerimento diretamente associado aos procedimentos de governança. Pensando num dos apelos de SOA, reuso, como é que se garante reutilização de serviços sem uma espécie de "centro de excelência SOA" em conjunto de um repositório controlado de serviços? Esse repositório deve garantir algumas coisas: Ser de uso comum a analistas de negócios e de TI, ser configurável para a definição de políticas de uso, possuir mecanismos de controle de acesso, possuir facilidades que controlem o ciclo de vida dos serviços além de outras coisas mais.

Outras funcionalidades (não ligadas diretamente a tecnologia) para a tomada de decisão de uma suite de BPM incluem frameworks de indústria que podem ajudar como "templates" para a aceleração da implementação de processos (por exemplo, a indústria de telecomunicações, cada vez mais, utiliza padrões estabelecidos mundo afora), metodologias de implementação de tais suites e também um "ecossistema" no mercado de desenvolvedores, técnicos e analistas.

Naturalmente, nenhum cliente precisa disso tudo num primeiro momento de suas iniciativas de BPM. Seria como pensar em se ter uma aperalhagem completa de cozinha para fazer ovo frito, não é verdade? O que considero como sendo um dos pontos mais importantes para avaliação de uma suite, do ponto de vista técnico, é sua modularização e facilidades de integração entre módulos. Isso me garantirá um início mais barato além de garantias para o crescimento dos meus projetos.

Luiz Phelipe Souza

Service Oriented Reference Architecture – Parte 1

"SOA não é um programa de computador a ser instalado e que vai resolver todos os problemas de TI. SOA é um estilo de arquitetura tecnológica com o objetivo de dar agilidade ao negócio das empresas. Sendo um estilo, ela tem traços marcantes: componentização para reuso, a modelagem e coreografia de processos, etc, já discutidos aqui. Mas quais são as melhores práticas para a materialização desses conceitos? O que a experiência tem mostrado como sendo o caminho mais efetivo?"

Ao fazer uma viagem de carro uma das primeiras atividades é levantar informações sobre o caminho (condições da estrada, locais de parada, etc). Isso acontece porque quando vamos encarar uma longa jornada por um caminho que não é do nosso dia-a-dia preferimos planejar para evitar surpresas.

Com a adoção de novas tecnologias não é diferente. Sempre procuramos planejar nossa jornada até sua implantação para minimizar os riscos envolvidos.

Da mesma forma de usamos mapas rodoviários e GPS em nossas viagens, alguns artefatos nos guiam na área de tecnologia da informação.

Neste primeiro artigo vamos começar a entender nosso GPS para a adoção de uma arquitetura orientada a serviços: a Service Oriented Reference Architecture ou SOA Foundation.

O primeiro modelo de referência é para a definição de um ciclo de vida para nossos componentes de negócio.

O objetivo do ciclo de vida é definir as etapas de captura das informações de negócio (processo, indicadores), a transformação dessas informações em uma especificação de tecnologia, a instalação desses componentes para a execução, o acompanhamento da saúde do processo de negócio e a realimentação dessas informações de saúde na etapa de captura das informações.

A figura 1 abaixo apresenta esse ciclo, suportado por governança e processos. Vamos detalhar mais o ciclo de vida no segundo artigo desta série.

O segundo modelo de referência é para o estabelecimento de um diagrama funcional, onde fica claro quais são as entidades necessárias para a execução do processo de negócio. Cada uma das “caixinhas” no diagrama funcional executa uma atividade tecnológica específica. Essa representação auxilia no reuso de componentes, além da escolha dos requisitos técnicos como melhor plataforma de execução e melhor nível de serviço.

Discutiremos mais sobre o diagrama funcional no terceiro artigo desta série.

O terceiro modelo de referência serve para a definição do modelo de desenvolvimento aderente ao ciclo de vida e ao diagrama funcional apresentados anteriormente.

O modelo de desenvolvimento tem como foco principal simplificar as complexidades específicas de cada ambiente e cada linguagem com o objetivo comum de produzir componentes reutilizáveis por uma arquitetura orientada a serviços, sem perder os investimentos já feitos e as capacidades e conhecimentos existentes.

No quarto artigo vamos falar mais sobre o modelo de desenvolvimento.

João Luiz Pereira Junior

Monitoramento de Processos: Quem não precisa disso? - 2/2

Entendida a idéia inicial de um evento, vamos repassar esta definição para o mundo dos processos de negócios. Imaginando um processo como uma série de atividades encadeadas, temos que imaginar os eventos ocorrendo em diferentes etapas dentro de uma atividade. Por exemplo, ao se invocar um determinado serviço, pelo menos dois eventos poderiam acontecer: um no início da atividade e outro no término da atividade. Se um processo contém várias atividades em cadeia, pode-se, então, prever que diversos eventos podem ser identificados e capturados por cada instância de execução. Se pensarmos agora que, em um projeto, precisamos saber o tempo médio de execução de um processo, bastará capturarmos o primeiro evento do processo (ex: start da primeira atividade) e o último evento (ex: exit da última atividade). A ligação de um “cronômetro” entre o primeiro evento e o último nos mostrará em quanto tempo o processo foi concluído. Se criarmos uma média de tempo de execução, podemos colocar este valor médio sob um critério de KPI e, com isso, avaliar seu desempenho.

O raciocínio do analista de TI, responsável pela construção dos indicadores a serem exibidos no painel, deve ser idêntico ao exemplo colocado acima. Supondo uma camada de coreografia de serviços que permeia uma série de sistemas e pessoas, a lógica para montagem das métricas e indicadores fica restrita a variáveis exibidas nesta coreografia. Se não há esta camada, será de responsabilidade dos desenvolvedores e analistas dos sistemas legados a geração de logs e/ou eventos relevantes na execução de seus sistemas. Esses logs serão as informações iniciais e fundamentais para o responsável pela definição técnica das métricas, KPIs e tudo mais previsto no painel de monitoramento.

O que uma solução de monitoramento pode prover

São inúmeras as funcionalidades que podemos imaginar para uma solução de monitoramento. Pensando na solução como um framework aberto, possível de se implementar praticamente qualquer controle em um processo de negócio, vamos procurar listar o que uma solução de monitoramento de processos deve prover, de forma gráfica e amigável:

• Monitoramento “durante o vôo” – O painel de monitoramento deve prover informações das instâncias (ativas e/ou concluídas) de todos os processos controlados.

• Tomada de ações – A partir de um painel operacional de monitoramento é possível prover opções de ações automáticas ou manuais para invocação de tratamentos de exceção ou contingência. Por exemplo, se um gestor do processo percebe uma parada numa instância (por exemplo, alguém que não executou ainda uma atividade humana), ele pode envolver uma terceira pessoa e/ou invocar uma ação alternativa (normalmente prevista no desenho do processo);

• Detecção de situações de anormalidade, exceção ou contingência – Assim como um gestor de processos pode interferir na execução dos mesmos, procedimentos automáticos podem ser invocados no caso da identificação de uma situação de anormalidade. Por exemplo, um processo controlado e medido por SLAs pode ter um tratamento automático de contingência quando o tempo total do processo atingir 70% do tempo previsto em contrato;

• Análise consolidada – A solução de monitoramento deve ser capaz de consolidar as execuções dos processos para apresentação através de gráficos, possibilitando o detalhamento (drill-down) de dados para análise de tendências. Neste caso, ferramentas de Business Intelligence podem ser úteis e simplificar o desenvolvimento;

• Indicadores de performance (KPIs) – Esse, com certeza, é o principal requerimento de um painel de monitoramento de processos de negócios. A solução deve mostrar, a partir das instâncias executadas, indicadores gráficos de desempenho com faixas consideradas ótimas, razoáveis ou ruins, por exemplo;

• Comparação de resultados real x simulado – Imaginando que uma solução de monitoramento pode estar inserida no contexto de um ciclo completo de BPM (da modelagem à monitoração), tal solução deve prover funcionalidades de exportação de resultados reais para futura comparação com dados simulados (ainda em tempo de análise). Isso será de grande valia para a melhoria contínua de um processo;

Considerações e pontos de atenção em um projeto

Um ponto muito reforçado por especialistas em arquitetura orientada a serviço é o envolvimento das áreas de negócio em todas as principais fases de uma iniciativa BPM/SOA na empresa. A implementação de um painel de monitoramento não será muito diferente. Projetos de monitoramento de processos envolvem, fundamentalmente, processos descritos pela área de negócios (usualmente, em ferramentas de modelagem BPMN) e indicadores de performance “ao alcance da mão” requeridos por gestores. Nós de TI, como responsáveis pelos cálculos das métricas para implementação dos indicadores, faremos, tão somente, tais medições em cima do processo já desenvolvido. Se as iniciativas de BPM na organização já consideraram o uso de uma camada de coreografia BPEL, excelente! A preparação do ambiente de monitoramento será uma derivação do que já estará sendo tratado pelo BPEL. O esforço será apontar nas atividades descritas no processo onde ocorrem os eventos relevantes e os cálculo/métricas que devem ser criados a partir dos eventos capturados. No cenário em que ainda não há uma camada de coreografia e um barramento de serviços bem definido, o grande sucesso do projeto estará na capacidade dos sistemas legados gerarem informações que poderão ser mapeadas como eventos de negócios. Uma vez bem estabelecido este mapeamento (ou seja, de logs ou traces gerados pelo sistema origem para eventos de negócios), o processo de construção do painel será similar ao modelo com BPEL.

Conclusões

Soluções de monitoramento de processos costumam encantar e encher de expectativas os gestores das áreas de negócio da empresa. A possibilidade de ter, ao alcance da mão, resultados operacionais e consolidados apontando tendências de mercados mostra a muitos o valor agregado de uma solução como essa e, normalmente, estes gestores serão os grandes patrocinadores de um projeto desta natureza. Ainda que seu projeto comece com a implementação de um painel de monitoramento, a partir de resultados e/ou logs de sistemas em produção, monte seu projeto com todas as etapas de um BPM, tendo sempre uma arquitetura orientada a serviços em vista. Naturalmente, as próximas ondas desta iniciativa passarão por redesenho de processos e implementação de uma camada de coreografia.

Luiz Phelipe Souza

Monitoramento de Processos: Quem não precisa disso? - 1/2

Uma empresa com milhões de clientes possui diversos sistemas, controles e mecanismos de registro de chamados no seu call center, mas, ainda assim, não é vista como um exemplo de atendimento pelo mercado. Seus sistemas nasceram motivados por urgências que atendiam interesses de unidades de negócio distintas, sem uma visão de arquitetura corporativa. Uma administração pró-ativa dos problemas enfrentados por seus clientes é praticamente impossível.

Esse é um real e clássico exemplo de necessidade imediata de controles consolidados e mecanismos pró-ativos de gestão de processos de negócios. O artigo a seguir descreve os principais pontos e características de uma solução de monitoramento de processos, um dos principais benefícios de negócio que uma arquitetura BPM pode prover a uma organização.

Objetivos de uma solução de monitoramento

Ilustrei acima um exemplo de um cenário de call center. De forma análoga, poderiamos citar uma situação onde gerentes de vendas querem saber, por exemplo, como andam as vendas Brasil afora, quanto falta para fechar a meta estipulada para uma determinada regional e onde estão os principais gargalos nos seus processos de vendas e, a partir de controles que mostram a tendência de um mercado consumidor, identificar oportunidades de negócio que levem a uma estratégia para revisão de processos para atender a um perfil específico ou o lançamento de um novo produto. Enfim, controles que, em última análise, levem a empresa a tornar-se especial, inovadora no seu mercado. De forma resumida, podemos listar os principais objetivos de negócio de uma solução de monitoramento de processos:

• Entendimento da execução e performance dos processos de negócio;

• Acompanhamento de medições e controles de acordos de níveis de serviço (SLAs);

• Melhoria na agilidade do processo através de tomada de ações automáticas;

• Analise consolidada da execução de processos de negócios que apóiem decisões pró-ativas de revisões de processos;

Ponto de entrada / saída de um projeto BPM/SOA

Pode-se considerar que uma solução completa de BPM envolve as seguintes etapas: (Re)Desenho, Implementação, Execução e Monitoramento. Não necessariamente, projetos de BPM devem iniciar por uma etapa de desenho ou modelagem. Podem acontecer situações em que o processo está bem definido, implementado e executado por sistemas proprietários como, por exemplo, um ERP integrado com outros sistemas legados. A “dor” da empresa, motivo que a levou a uma solução inicial de BPM, pode estar na falta de monitoramento de um processo já existente e em execução.

A base de tudo: Eventos

Para entendermos o conceito fundamental de uma solução de monitoramento, falamos agora na definição de um evento. Um evento pode ser entendido como uma ocorrência de log, tracing, gerenciamento de aplicação e/ou evento de negócio que encapsula dados num formato consistente para tratamento por outros sistemas (com isso, sendo base para os conceitos de autonomic computing). Um exemplo de especificação de eventos é o formato CBE (Common Base Event). A IBM e a Cisco, em outubro de 2003, anunciaram este formato como um padrão facilitador de troca de informações de logs e tracing entre sistemas heterogêneos. Este formato, descrito em XML (seu schema é definido em http://xml.coverpages.org/CBESchemaV20.html), informa a quem o consumir, informações relevantes do estado da aplicação que disparou o evento. Informações do serviço que originou o evento, severidade, número de ocorrências daquele evento além de extensões que descrevem mais a ocorrência são exemplos de dados que podem surgir em um CBE.

O link http://www.ibm.com/developerworks/autonomic/library/ac-cbe1/ descreve, com mais detalhes, o que é o CBE, seu formato e ainda leva a outros endereços com a especificação formal.

Luiz Phelipe Souza

Tornando a implementação o menos dolorosa possível

“Tá bom, tudo o que vimos até agora faz sentido e até parece interessante, mas como mudo a cultura da minha empresa para adotar uma solução no estilo de BPM/SOA?”

Essa é a primeira pergunta que aparece na mente de qualquer um que entenda os benefícios da arquitetura orientada a serviços. Isso porque a palavra chave dessa pergunta é cultura e, no geral, mudanças culturais não são amplamente aceitas.

Para aqueles que já têm algum tempo de TI, lembro que perguntas semelhantes apareceram quando surgiu a arquitetura cliente-servidor, quando fomos para o modelo web-based, mais uma vez na arquitetura web de três camadas, no famoso J2EE e por aí vai. Foram tempos árduos para os gerentes de projeto que implementaram essas modelos tecnológicos nas suas empresas, mas não faltaram benefícios (e até algumas promoções).

Com a arquitetura orientada a serviços não é diferente. Tudo vai depender de quão organizado o projeto de implementação vai começar.

Para aqueles que chegaram até aqui e estão querendo parar de ler porque “minha empresa nunca vai ter SOA”, eu queria só adicionar mais um ponto:

Praticamente todas as empresas vão adotar SOA de uma forma ou outra e isso se dá por um motivo simples: todos os fornecedores de tecnologia estão produzindo soluções SOA-enabled. Convido vocês a um teste: Escolha um fornecedor de tecnologia e faça a seguinte pesquisa no google:

+Nome_do_Fornecedor+SOA

As eferência para IBM e SOA já chegam a quase 3 milhões de registros.

Mas voltando à implementação, nosso objetivo é torná-la o mais consistente e o menos dolorosa possível (não necessáriamente nessa ordem!). Além de pensar em um roadmap de implementação que antecipe os benefícios.

Para que isso seja possível o segundo passo é montar um mapa de prioridades. Costumo fazer isso com um gráfico de bolhas representando benefício x complexidade x custo. Como o exemplo abaixo:

Tabela 1 - Mapa de Prioridades

Da Tabela 1 geramos os dados do Gráfico 1, de onde podemos escolher dentre dois candidados a primeiro projeto: o Portal ou a Coreografia. É importante lembrar que esse gráfico é contruído considerando o custo como tamanho das esferas no gráfico. E o que buscamos são projetos com o maior benefíco com a menor complexidade e o menor custo.

Gráfico 1 - Mapa de Prioridades

“Mas se esse é o segundo passo, qual é o primeiro?”

O primeiro passo e mais importante é o estabelecimento de um grupo multi-disciplinar (pessoas de tecnologia e pessoas de negócio) que irá ser responsável pelo sucesso da implementação.

Historicamente a implementação de novos modelos tecnológicos sempre foi liderada por tecnologia. Isso não se aplica mais: tecnologia sozinha não vai ter subsídios para escolher entre Portal ou Coreografia no nosso exemplo acima. E esse nosso primeiro passo é também a primeira mudança cultural.

Esse grupo é conhecido novos modelos de administração como Centro de Competência ou Centro de Excelência. O Centro de Excelência em SOA é responsável por alguns pontos críticos:

• Roadmap de Implantação
• Arquitetura Corporativa
• Modelo de Governança de TI
• Modelo de Governança de Negócios
• Plano de Capacitação
• Endomarketing para divulgação do novo modelo

Por último, mas não menos importante, o responsável pelo Centro de Excelência deve ser um executivo da companhia, especialmente alguém que tenha interesse direto nos resultados obtivos pelo novo modelo tecnolócio. Esse sponsor é peça chave para que a implantação tenha sucesso.

João Luiz Pereira Junior