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

Novo Shopping de Tarefas!

Até agora apresentamos conceitos para facilitar o entendimento de todos sobre um projeto de BPM. Acredito que aqueles que estão acompanhando nossos posts, já possuem um conhecimento (no mínimo) básico do que é, e os beneficios de uma implementação de BPM by SOA.  Com essa premissa, a partir de agora publicaremos também outros tipos de posts (não somente posts conceituais), tais como Informações de Novidades de Soluções de Mercado e Dicas de Como Fazer, objetivando extimulá-los a "Parar de Falar e Começar a Fazer". Todavia isso não implica que não publicaremos mais artigos conceituais/didáticos, apenas suportaremos estes conceitos com dicas de como implementar.

Logo para começar essa nova onda, vou detalhar o que tem dentro do novo presente da IBM: WebSphere Portal 6.1.  Vou apresentar nesse post as novidades em relação ao Novo Shopping de Processos da IBM lançado no último mes de Junho. Abaixo seguem as novas características do WebSphere Portal Server 6.1, do ponto de vista de integração com a suite de BPM da IBM:

Analisando o novo portal da IBM (WebSphere Portal 6,1), no ponto de vista de implementar uma Interface Única de Acesso do Usuário aos processos de negócios de uma corporação, podemos notar 5 mudanças fundamentais em relação a versão anterior do Produto (WebSphere Portal 6.1):

• Instalação e configuração Simplificada: Objetivando simplificar a integração do WebSphere Portal com sua suite de BPM (Websphere Process Server 6.1, WebSphere Monitor 6.1 e Modeler Publishing Server 6.1), a IBM facilitou a vida dos especialistas em infraestrutura, padronizando uma única forma de integração, através da Instalação do Client do Process Server 6.1, deixando de existir a outras duas opções que existiam na versão 6.0 (Instalação de Um Portal em um servidor de Process Existente, e a opção de instalação de um container simplificado de BUsiness Process junto com a instalação do portal). Em um próximo post, detalharei o novo processo de instalação e suas possíveis variações arquiteturais.

• Novo Portlet para Gerenciamento de Processos: Diferente da versão 6.0 do Portal, que só possui portlet para visualização das tarefas pendentes, a partir da versão 6.1, a IBM está  disponibilizando um portlet para analise das instancias de processos em execução, bem como para a ciração de uma nova instancia de um processo específico, até a versão 6.0, para executar essas ações, era necessários utilizar um aplicativo web que era instalado no WebSphere Process Server (BPC Explorer).

• Melhorias no Portlet de Lista de Tarefas: Na versão 6.1, foi melhorado o portlet de listas de tarefas, possibilitando a criação de filtros customizados para visualização das tarefas pendentes (ex.: filtro para visualizar apenas as tarefas de criação de uma nova conta de cliente), além de ter novos campos na visualizaçào das tarefas, tais como Data de Expiração e Prioridade.

• Novo Portlet Genérico para Processamento de Tarefas: Agora é possível executar uma tarefa no portal, mesmo que não tenha sido criado uma interface de portlet para ela (similar a visualização através de interfaces geradas automaticamente no BPC Explorer). Sendo possível agora completar, salvar e editar qualquer tipo de interação humana, mesmo ela não ter sido projetada para ser um portlet.

• Página Padrão para Execução de Tarefas: Exatamente por possibilitar executar tarefas que não foram projetadas para rodar como portlet, agora existe uma página padrão para execução de tarefas, as quais não foram especificadas um Unique ID de página para a execução da mesma. Essa página possui um Portlet Genérico para Processamento de Tarefas (descrito acima). Por ser uma página Real no WebSphere Portal, ela pode ser customizado como qualquer outra página do portal.

Com esses 5 pontos, a nova versão do portal se integra mais facilmente a suite de BPM da IBM, se tornando assim a interface ÚNICA e DEFINITIVA para execução de tarefas que necessitam interações humanas. Nos próximos posts, apresentarei mais detalhes sobre essas novidades.

Rafael de Oliveira Osório

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

Interação Humana: Formulários e mais formularios! Como facilitar a minha vida?

Conforme citado anteriormente, os processos que necessitam de uma interação humana estão entre os mais comuns dentro das empresas.

Geralmente, esses processos são iniciados com uma entrada de dados (por exemplo, o preenchimento de uma proposta de crédito imobiliário) e posteriormente precisam de uma aprovação simples (a validação da proposta).

Estudos comprovam que, neste tipo de processo, a tarefa que demanda maior tempo de implementação, o que implica em grande custo no projeto, é a criação de formulários para interface com o usuário. Estas interfaces cada vez mais têm a necessidade de ter o conceito de formulário rico, que possui as seguintes características:

• Interface amigável, baseada no conceito de wizard para o preenchimento;
• Validadores de campos que auxiliem o correto preenchimento;
• Lógica de interface, possibilitando exibir ou não um campo conforme o preenchimento pelo usuário;
• Possibilitar a utilização de assinaturas digitais;
• Permitir o controle em nivel de pixel durante o processo de impressão.

Além dos itens citados acima, é interessante que a interface seja de fácil criação, possibilitando começar o seu desenvolvimento durante a etapa de modelagem do processo de negócio.

Devido a essas características, os grandes fornecedores de suite de BPM, cada vez mais utilizam padrões de mercados (como o XForms), para o desenvolvimento desses formulários eletrônicos ricos. Em futuros posts, explicaremos mais detalhes dos conceitos básicos de um formulário eletrônico. Porém, para iniciar seu estudo no uso de Formulários Eletrônicos em um cenário de BPM, sugiro a leitura do artigo "Getting started with Lotus Forms in the WebSphere Business Process Management Suite" no Developerworks já mostrando a integração do Forms 3.0.1 com a suite WebSphere BPM 6.1.

Rafael Osório

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