A abordagem tradicional para SOA está baseada nas premissas da modelagem, simulação, automação, monitoração e gerência de processos de negócio, i.e, o ciclo de vida de BPM (Gerenciamento de Processos de Negócio). Existem diversos cenários, entretanto, onde esta premissa não se torna válida.

Caso a nossa empresa ou o problema em questão apresente a lista de condutores abaixo, uma abordagem arquitetural mais adequada é a orientação por eventos.

Condutores Arquiteturais para CEP (Processamento de Eventos Complexos)

• Agilidade e adaptabilidade.
• Gerenciamento por exceção.
• Respostas imediatas.
• Respostas instantâneas a eventos que ocorrem fora do seu eco-sistema de parceiros.
• Resposta a situações não antecipadas.

O CEP como um contraponto ao BPM tradicional

Dois cenários clássicos deste contexto são aplicações que monitoram fraudes e aplicações que reagem a eventos de mercado para sistemas de suporte a decisão de investidores. Uma abordagem tradicional baseada em BPM geraria um esforço absurdo na tentativa de modelar diversos caminhos e percursos de processos e situações, sendo que muitas destas situações ainda não são conhecidas.

No paradigma CEP (Complex Event Processing), a chave é adaptar software chamados de máquinas de eventos para ouvir a determinados tipos de eventos que necessitem ser monitorados. Estes eventos podem ser capturados de bases de dados, ERPs, CRMs e outros elementos arquiteturais do seu eco-sistema. A partir da sua máquina de eventos, processos podem ser iniciados ou outras ações podem ser disparadas. Por exemplo, se três eventos de uso de cartão de crédito ocorrem em um intervalo de cinco minutos com soma total acima de 500 reais, a máquina de eventos poderia solicitar a um operador do call-center ativo para retornar uma ligação a um cliente.

O CEP não invalida o BPM, assim com um contraponto musical não invalida a melodia central da música. Pelo contrário, o CEP enriquece o BPM, pois permite que processos de negócio sejam invocados de formas inesperadas. No cenário acima, o processo de monitorar compras do cliente pode ser invocado a partir de uma máquina de eventos, gerando maior eficiência e assertividade em uma administradora de cartão de crédito.

Uma arquitetura de TI que suporte o modelo CEP é chamada de EDA, i.e, Event Driven Architecture. Dentro do amplo leque de ferramentas SOA, temos diversos fornecedores com bons produtos EDA/CEP.

Esta é uma tradução pessoal do SOA Manifesto Guiding Principles criado por Ali Arsanjani, Thomas Erl, Grady Booch e outros notáveis.

Bons projetos SOA!

O Manifesto SOA

A orientação por serviços é um paradigma que orienta o que você faz. A arquitetura orientada por serviços (SOA) é um tipo de arquitetura que resulta da aplicação da orientação por serviços. Nós aplicamos a orientação por serviços para ajudar organizações a entregar valor de negócio de forma sustentável, com agilidade aumentada e custos eficazes, alinhado às necessidades de mudanças nos seus negócios.

Através do nosso trabalho nós priorizamos:

Valor para o negócio sobre estratégias técnicas.
Objetivos estratégicos sobre benefícios específicos de projetos.
Interoperabilidade intrínseca sobre integrações personalizadas.
Serviços compartilhados sobre implementações com propósitos específicos.
Flexibilidade sobre otimização.
Refinamentos evolucionários sobre a procura da perfeição inicial.

Isto é, embora nós valorizemos os valores da direita, nós valorizamos mais os itens à esquerda.

Esta é uma tradução pessoal do SOA Manifesto criado por Ali Arsanjani, Thomas Erl, Grady Booch e outros notáveis. Acredito no manifesto. Também aderi ao manifesto, ao qual me tornei signatário.

Bons projetos SOA!

Com a popularização de projetos SOA, também houve um renascimento do conceito de motores de regras (Rule Engine). Mas o que são motores de regras?

Um motor de regra é um sistema computacional que tem a capacidade de executar um conjunto de regras de negócios em um ambiente de produção. Eles são chamados em inglês de BRMS (Business Rules Management Systems).

Um BRMS não nos é útil se não entendermos o conceitos primário de uma regra de negócio, descrito abaixo.

Regras de Negócio - Átomos de Negócio do Domínio

Uma regra de negócio expressa uma restrição sobre um domínio de negócio. Um exemplo simples é mostrado abaixo:
Se o cliente possuir cadastro de crédito positivo no SERASA, então o desconto sobre o financiamento será de 1%

A premissa de um motor de regras é que as regras podem ser expressas e mantidas em uma linguagem natural (ou uma aproximação) e portanto permitem uma velocidade e responsividade muito maior da TI a alterações regulatórias e de inovação nas áreas de negócio. Em tese, a mudança da regra de desconto de um financiamento de crédito pode ser totalmente implementada por um analista de negócio em um sistema BRMS, sem conhecimentos profundos dos complexos padrões WS-* e de linguagens pouco produtivas como Java, COBOL ou C++.

Regras não são um agrupamento desordenado de textos. Um modelo de regras deve ser identificado e organizado a partir de um conjunto de critérios formais tais como:

• um vocabulário de negócio que exprime a semântica dos conceitos sendo trabalhados em um domínio - Fatos;
• um conjunto de proposições que permitem a geração de conhecimento a partir destes fatos.

No exemplo acima, podemos identificar como fatos primários o CLIENTE e o FINANCIAMENTO. A proposição do exemplo usa o crédito do CLIENTE para estabelecer uma política de desconto sobre o FINANCIAMENTO.

Um modelo formal para compreender como estruturar regras de negócios é o OMG SVBR, cuja versão 1.0 está disponível aqui. Recomendo fortemente que os iniciados em BRMS estudem este documento antes de abrir e trabalhar com uma suíte BRMS. O documento pode parecer tedioso, mas assim como para dirigirmos um carro precisamos de aulas de legislação, precisamos entender que suítes BRMS estão baseados em conceitos não tão populares que precisam ser entendidos. Para os mais apressados, uma boa introdução ao tema está disponível aqui.

Outras especificações relacionadas são o OMG BMM (que motra o papel das regras de negócio dentro da modelagem de negócio) e o OMG PRR (que mostra como um programa computacional pode ativar inferências a partir de um conjunto de regras de negócio e uma memória de trabalho). O PRR é, em termos leigos, o mecanismo de inteligência artificial usado pelos motores de regras. O BMM, por sua vez, permite entender como o BRMS está ligado com o BPM e as estratégias corporativas.

Suítes BRMS

Um BRMS parece ser apenas uma ferramenta, mas como o próprio nome diz ele se refere a um conjunto de ferramentas, onde cada ferramenta tem um propósito. Listo abaixo algumas categorias de ferramentas BRMS:

Um dos gaps existentes nos times de desenvolvimento de software é a distância entre a concepção e desenho da arquitetura e sua efetiva realização. Motivos para este problema incluem:

• Mudanças de escopo e mudanças nas prioridades dos condutores e requisitos arquiteturais,
• Ausência de desenvolvedores na definição da arquitetura. Quando uma pessoa não participa da definição de um plano arquitetural, ela tem dificuldades naturais em se comprometer com aquele planejamento.
• Dificuldades para uma pessoa qualquer (inclusive o arquiteto) para manter o rigor das suas próprias definições dentro da complexidade e pressão de um projeto.
• Complexidades nas transformações e na rastreabilidade dos requisitos de negócio em condutores, dos condutores em requisitos arquiteturais, dos requisitos arquiteturais em mecanismo de análise, dos mecanismos de análise em mecanismos de desenho e estes em mecanismos de implementação, que possibilitam que um código fonte seja escrito.

Práticas arquiteturais como a arquitetura coletiva e a gestão do ciclo de vida da arquitetura de software, que descrevemos em outros posts, podem nos ajudar a minimizar estes problemas.

Uma outra ajuda neste sentido foi lançada recentemente no JBOSS World 2009 que ocorreu semana passada em Chicago. O projeto SAVARA tem por objetivo garantir um modelo vertical completo de rastreabilidade de requisitos de negócio em projetos SOA, conforme a figura abaixo mostra.

Este projeto é baseado em uma metodologia de governança de serviços da Red Hat e Cognizant e apresenta como conceito interessante o uso da CDL como técnica de representação arquitetural dos requisitos arquiteturais. Do que pudemos examinar até o momento, o projeto utilizará como tecnologia central o JBOSS Drools Guvnor como ferramenta de repositório. O Guvnor, conceitualmente, é uma implementação da especificação Java para conteúdos de repositórios (JSR 170).

Embora ainda tenhamos que esperar que este projeto possa amadurecer e se tornar um produto real, é no mínimo uma satisfação ver frutos dos conceitos de arquiteturais testáveis e métodos de avaliação arquitetural como o ATAM.

Um conceito muito importante no mundo SOA é a escolha do ponto de entrada. Um ponto de entrada descreve para uma empresa, área de negócio ou mesmo uma unidade de negócio qual a melhor abordagem arquitetural para uma automação SOA.

Os principais pontos de entrada SOA são:

• Integração de pessoas;
• Integração de processos;
• Integração de aplicações (conectividade);
• Integração de informações;
• Reuso.

Um ponto de entrada de pessoas por exemplo irá demanda uma abordagem arquitetural baseada em serviços visuais. Tecnologias como portais, mash-ups, portlets, sindicalização, colaboração, fluxos de trabalho/workflows devem fazer parte da sua agenda técnica.

Um ponto de entrada de processos, por outro lado, irá demanda uma abordagem arquitetural baseada em serviços de processo e serviços de negócio. Tecnologias como BPMN, BPEL, orquestração e coreografia e processos e motores de execução de processos farão para da sua agenda técnica.

Um ponto de entrada de integração de informações, para citar um outro exemplo, nos leva a uma plataforma de serviços de dados. Tecnologias e conceitos como replicação de dados, federação de dados, bancos federados, caches, GEDs, entre outros, irão fazer parte da sua agenda.

A natureza operacional da sua unidade de negócio determina os pontos de entrada SOA

Pode parecer que *nós*, analistas e arquitetos, temos livre arbítrio para escolher qual o ponto de entrada que desejamos usar. Entretanto, isso não pode estar mais longe da verdade.

A natureza e o modelo operacional de uma empresa, uma área ou mesmo unidade de negócio demanda maior ou menor necessidade de integração de dados e integração de processos. Nem sempre uma grande integração de dados e uma grande integração de processos é necessária. Uma holding, por exemplo, necessita de grande integração de dados mas baixa integração de processos. Cada empresa que compõe a holding, entretanto, pode ter diferentes necessidades e assim recursivamente nas suas unidades de negócio.

Conforme estas necessidades de integração, podemos derivar quais capacidades de TI serão mais úteis e mais corretas para que possamos então escolher um melhor modelo SOA para a nossa área, unidade de negócio ou empresa. Escolher o SOA correto para a sua unidade de negócio tem a ver com eficácia e com o alinhamento das ações de TI com a arquitetura de negócio da sua empresa.

Para os mais céticos, basta olhar os portifólios de produtos que trabalham com SOA. A JBOSS, por exemplo, tem diferentes suítes de produtos para diferentes abordagens arquiteturais. O JBOSS MetaMatrix (TEIID), por exemplo, é para o SOA baseado em serviços de dados e faz parte do JBOSS Data services Platform. O JBOSS jBPM, por outro lado, é para o SOA baseado em serviços de processo e serviços de negócio. O JBOSS Portal, como um terceiro exemplo, é para o SOA baseado em integração de pessoas e faz parte do Portal Platform.

Nas empresas líderes SOA de mercado (IBM, Oracle/BEA/SUN, TIBCO), a segmentação do portfólio é ainda mais aparente e os pontos de entrada SOA são uma boa forma de digerir e entender como a oferta de valor destas empresas pode ser melhor para a sua empresa.

Antes de começar a sua implementação SOA, então, faça a seguinte pergunta: “Qual o melhor SOA para a minha empresa?”.

Fizemos na semana passada uma apresentação sobre o modelo de computação nas nuvens e a sua interação com novos modelos de negócio e novos modelos técnicos tais como software como serviço, virtualização de hardwares e o modelo de cauda longa.

A apresentação está disponível aqui para os interessados:

Diversas empresas da primeira onda de SOA criaram um vasto portifólio de serviços em suas implementações de automação de processos de negócio. Muitas destas empresas, entretanto, criaram serviços não governados, i.e, serviços sem controle (sem cadeias de autoridade, controle de mudanças, versões, relacionamento entre serviços, políticas de reuso). A consequência foi um desalinhamento entre o valor esperado pelo programa SOA e um valor realmente obtido.

A governança SOA surge neste contexto de desalinhamento. O seu objetivo é prover algum nível de controle destes serviços para que possamos gerir cuidadosamente o investimento de TI destas iniciativas de melhorias.

Para tornar concreto nosso raciocínio, vamos usar um exemplo prático associado ao desenvolvimento de WebServices. Podemos ter uma política de governança SOA para testes de WebServices que diga que todo arquivo .WSDL seja interoperável conforme com o padrão de interoperabilidade de WebServices WS-I Basic Profile 1.1. Este exemplo de governança garante que um WSDL criado em Java será compatível com um cliente de serviço escrito em ASP.NET.

Um centro de excelência SOA, que descrevemos em outro post, seria responsável pela implementação deste tipo de política de governança em uma organização.

Fizemos recentemente uma apresentação sobre este tópico, que gostaria de compartilhar neste nosso espaço.

Arquitetos de software de verdade investem grande parte do seu aprendizado em técnicas arquiteturais. Exemplos destas técnicas incluem o modelo de visualização 4+1 de Kruchten, processos de software, os modelos SEI QAW, ATAM, CBAM, V&B e ADD, os modelos de requisitos FURPS+, ISO 9126, ISO SQUARE, as recomendações arquiteturais da norma IEEE 1471, técnicas de liderança de times e mesmo modelos de arquiteturas corporativas como o TOGAF ou o Zachman Framework.

A notícia boa é que este corpo de conhecimento técnico permite que o arquiteto projete, elicite requisitos, modele, experimente, prove conceitos com código, acompanhe a sua equipe e edifique toda a arquitetura técnica de um produto.

A notícia ruim é que mesmo este corpo gigantesco não garante o bem mais esperado de uma arquitetura de software, que é o alinhamento às estratégias de uma organização.

A notícia pragmática, então, é uma arquitetura de software somente deve existir para servir à uma arquitetura de nível superior, chamada de arquitetura de negócio. A arquitetura de negócio não é um super-conjunto da arquitetura de software. Ela é apenas uma arquitetura que existe em outro plano.

Uma arquitetura de negócio é uma macro-organização que descreve o modelo operacional de uma organização, suas áreas de negócio, seus processos de negócio nucleares e os seus atores de negócio.

Para tornar o concreto o nosso raciocínio, uso como exemplo o eTOM dentro so segmento de TELECOM. o eTOM é um guia com a descrição dos processos de negócio para um provedor de serviços de telecomunicações.

Um outro exemplo concreto é o SCOR, modelo de referência para empresas que possuam complexas cadeias de fornecimento (supply-chains).

Um terceiro exemplo, dentro do governo Brasileiro, é a empresa de referência da ANEEL. Esta empresa de referência serve como modelo operacional para qualquer concessionária de distribuição de energia elétrica, descrita no documento supracitado através de um conjunto de motivadores de negócio, processos de negócio, regras de negócio e modelo organizacional.

Um quarto exemplo é o ITIL, que é uma arquitetura de negócio para operações e serviços de TI.

Ao saber mais do contexto onde atuamos como arquitetos, podemos escolher entre soluções técnicas mais adequadas e coerentes. Podemos usar melhor os recursos escassos da TI e gerar mais valor de negócio para estas empresas.

Para se tornar um melhor arquiteto e saber mais sobre arquiteturas de software, estude mais as arquiteturas de negócio das verticais de atuação da sua empresa.

Pensamento do dia: A primeira lei da automação, por Bill Gates - “A automação de um processo de negócio eficiente irá aumentar a sua eficiência operacional”

Realizamos recentemente uma palestra na SUCESU-MG sobre Arquiteturas de Negócio no grupo de trabalho de BPMS. Uma arquitetura de negócio é uma peça importante na estruturação e entendimento do modelo de negócio de uma organização e se constitui de ferramenta essecial para analistas de negócio e também arquitetos de TI.

Em particular, discutimos nesta apresentação o conceito de arquiteturas de negócio, modelos operacionais, capacidades corporativas e como estes conceitos são determinantes para facilitar implementações BPMS em organização. Discutimos também o anti-padrão “Ferramentas Primeiro”, onde procuramos mostrar que ferramentas BPMS não podem ser o elemento central de uma programa de melhoria BPM.

Disponibilizo a apresentação abaixo para os interessados no tema.

Arquiteturas de Negócio