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

Vemos muitos projetos que falham por problemas gerenciais. Um destes problemas é a distância entre o gerente de projeto e a sua equipe. Times que não se sentem orientados e aconselhados diariamente perdem o seu foco e se dispersam. Para combater esta distância, devemos fomentar e incentivar a figura do líder técnico de desenvolvimento (que em muitas empresas também é o arquiteto de sistemas).

O líder técnico de desenvolvimento mantém o time unido e coeso. Ele mantém a consistência técnica do produto de software sendo construído e atua como um coach para todo o time para os problemas técnicos e de ausência de motivação, que são comuns em projetos complexos e com prazos desafiadores.

O líder técnico/arquiteto é o contraponto musical do gerente de projeto. O líder técnico e o gerente de projeto atuam como um par-alfa de lobos em uma alcatéia na caçada pelo sucesso do projeto.

As fronteiras entre o Gerente de Projeto e o Líder Técnico de Desenvolvimento

Adapto abaixo um trecho do livro Applied Software Architecture, de Christine Hofmeister, Robert Nord e Dilipe Soni, que explicita a fronteira entre a gerência de projeto e a liderança técnica de projetos.

Pensamento do dia - Eclesiastes 4:9 Melhor é serem dois do que um, porque tem melhor paga do seu trabalho. 4:10 Porque se um cair, o outro levanta o seu companheiro.

Diversas empresas já possuem iniciativas SOA em andamento ou pensam em fazê-lo em breve. Entretanto, poucas empresas no Brasil tem discutido o conceito do Centro de Excelência. Endereço neste artigo o conceito e a função do centro de excelência em implementações SOA.

Em termos simples, um Centro de Excelência (CDE) é um time multi-disciplinar dentro de uma empresa que promove melhores práticas, conhecimento e a implementação de novas soluções dentro de um determinado escopo. Um escritório de projetos (PMO), como exemplo, é um centro de excelência para gerência de projetos. Um CDE SOA faz este trabalho dentro do universo SOA, que envolve um grande conjunto de conhecimentos e habilidades necessárias para a sua implementação.

Tipos de Centros de Excelência SOA

De acordo com um excelente artigo de auxílio na montagem de centros de excelência SOA, podemos classificar os CDE em três tipos - Acadêmico, Técnico e Técnico Avançado. As principais funções destes CDEs são descritas abaixo:

Membros de um Centro de Excelência SOA
Quem irá participar de um centro de um excelência SOA é decisão do CIO, mas a recomendaçào primária é que arquitetos, times de infra-estrutura, gerentes de produtos e vendas e influenciadores de negócio e técnicos estejam envolvidos, bem como o chefe de tecnologia (CTO) e o próprio CIO.

Pudemos acompanhar um CDE em uma empresa que está iniciando uma implementação SOA recentemente e notamos um forte envolvimento do CIO, CTO e time de arquitetura, bem como pessoas de áreas de negócio e produtos em um modelo similar ao da figura abaixo.

Para os mais interessados, um bom artigo que endereça este tema é discutido na revista CIO Zone. Um webcast a respeito está disponível também no excelente site SearchSOA da TechTarget.