Mês: dezembro 2013

O padrão VETRO e a integração de sistemas

~ Marco Mendes ~ Deixe um comentário

Integrar aplicações em diferentes tecnologias, plataformas ou sistemas operacionais pode ser um formidável desafio a desenvolvedores e arquitetos. Observo nas empresas códigos muito desorganizados e muita confusão quando o assunto é integrar aplicações. Compilo neste post um pequeno padrão arquitetural para ajudar a resolver problemas de integração.

Conheça o padrão VETRO

Vamos aprender a usar este padrão em um exemplo fictício onde precisamos buscar os dados de um determinado cidadão do sistema da receita federal e gravar estes dados em um banco de dados local em formato SQL.

1. VALIDAR. 

O primeiro passo recomendado de toda integracão é realizar a validação dos dados recebidos. A validação pode verificar se o objeto de dados (um esquema XML ou texto JSON) está bem formado.

Como os dados são gerados por aplicações externas, é sempre boa prática “desconfiar” dos dados que estão sendo recebidos, pois eles podem ter sido modificados na estrutura de negócio ou no formato técnico sem aviso prévio.

No exemplo dado, poderíamos checar se a mensagem XML com os dados de um cidadão estão em conformidade com o esquema XSD esperado.

2. ENRIQUECER

O termo enriquecer tem por objetivo adicionar dados adicionais ao pacote de dados recebido. Muitas vezes isso é necessário para que o pacote de dados esteja compatível com o formato esperado pelo destinatário.

No exemplo dado, poderíamos enriquecer a mensagem XML com os dados do cidadão com a informação do login do usuário que esteja usando a aplicação. Estamos considerando que esta informação nova poderia ser usada para auditoria

3. TRANSFORMAR

O próximo passo é realizar a transformação dos dados (seja no formato dos dados ou protocolo técnico). No nosso caso, queremos extrair da estrutura XSD e colocar em um formato universal da plataforma que estamos usando.

Por exemplo, se estivéssemos escrevendo estes códigos em Java ou C#, poderíamos criar um objeto POJO ou POCO com os dados do cidadão enriquecidos com o login do usuário.

4. ROTEAR

Agora estamos próximo do fim e neste passo estamos fazendo o roteamento da informação para o seu destino. No nosso caso, iremos abrir a conexão (IP e porto) com o banco de dados onde iremos salvar o nosso POJO ou POCO com os dados do cidadão.

Em cenários mais elaborados, o roteamento pode envolver rotas complexas.

5. OPERAR

Finalmente, iremos gravar os dados no banco de dados. O passo operar implica em entregar a informação para o destinatário final e terminar a rotina de integração.

O padrão VETRO pode ser implementado através do padrão de desenho cadeia de responsabilidades em Java ou C# e curiosamente forma a base de vários produtos de ESB do mercado. Em projetos SOA, chamamos estas lógicas de serviços de mediação, que também possuem a mesma estrutura básica.

Independente da tecnologia ou plataforma, entretanto, organizar um código desta forma nos fornece limpeza semântica e boa organização em lógicas de integração.

Boas integrações!

Pensamento do dia:
“Manifest plainness,
Embrace simplicity,
Reduce selfishness,
Have few desires.”,
Lao-tzu

Plataformas Arquiteturais

~ Marco Mendes ~ Deixe um comentário

Phillipe Kruchten disse uma vez que a vida do arquiteto é uma longa sucessão de decisões sub-ótimas e parcialmente tomadas no escuro. Nada mais verdadeiro, em minha opinião.

Mas qual seria a decisão mais importante que um arquiteto deve tomar. A decisão sobre o estilo da arquitetura é sem dúvida uma destas decisões. Alguns estilos arquiteturais incluem:

  • Cliente-Servidor
  • P2P
  • Multicamadas (n-tier)
  • Centrado em serviços de negócio (SOA)
  • Centrado em processos de negócio (BPMS)
  • Centrado em computação paralela massiva (Grid)

No que tange à tecnologia, entretanto, o conceito da plataforma é sem dúvida a decisão mais importante. A plataforma é o elemento técnico que dá vida ao estilo arquitetural. Uma plataforma é um arranjo de softwares e servidores organizados de forma coerente para resolver problemas comuns no desenvolvimento de software. Dois exemplos comuns de plataformas incluem o Java EE e o Microsoft .NET. Um outro exemplo de um plataforma é o LAMP, que é um arranjo composto de sistema operacional baseado em Linux, servidor Web Apache httpD, servidor de banco de dados MySql e linguagens dinâmicas como PHP, Perl ou Python.

O Java EE,  .NET ou LAMP são usados normalmente para sistemas de informação Web. Naturalmente existem cenários da realidade de mercado onde necessidades mais específicas surgem. Para estes cenários existem outros tipos de plataformas de mercado, muito além do Java EE e o .NET.

Exemplos incluem:

  • Plataformas de ERP/MRP (Enterprise Resource Planning/Material Resource Planning), usadas para automatizar processos de suporte de organizações. Exemplos de produtos nesta linha são o SAP ECC, o Oracle PeopleSoft e Oracle JD Edwards.
  • Plataformas de portais usadas para a criação de sites que unifiquem informações de diversas fontes. Exemplos incluem o Microsoft SharePoint, o Oracle Portal ou o IBM WebSphere Portal.
  • Plataformas de serviços interoperáveis para estilos centrados em serviços SOA. Exemplos incluem o Microsoft WCF ou o Apache Tuscany (padrão SCA).
  • Plataformas de automação de processos de negócio (BPMS) para empresas que estejam e estágios avançados de implementações BPM. Exemplos incluem o IBM Business Process Manager ou o Oracle BPM.
  • Plataformas de serviços de decisão (BRMS) para empresas que busquem flexibilidade e responsividade extrema para as suas regras de negócio. Exemplos incluem o IBM ILOG Operational Decision Management ou o Redhat JBOSS Drools.
  • Plataformas de BI/ETL para o suporte a inteligência de negócios avançada. Exemplos incluem a suíte de produtos IBM Cognos, Microsoft SISS ou Oracle Hyperion.
  • Plataformas de integração de aplicações chamadas de ESB (Enterprise Service Bus). Exemplos incluem o SAP PI, IBM WebSphere ESB e o Microsft BizTalk.

Se escolhemos uma plataforma arquitetural inadequada teremos graves problemas durante o projeto. Curiosamente, muitos “arquitetos” consideram a plataforma como dada e nem sequer pensam nisso. É a síndrome do arquiteto de uma plataforma só, que coloca a tecnologia na frente do problema.

Arquitetos de soluções racionais agem na direção inversa. Eles tem a mente aberta e fazem uma análise dos condutores arquiteturais. A partir destes condutores eles recomendam a plataforma mais apropriada que irá promover o melhor balanceamento dos condutores.

Em cenários mais sofisticados, uma solução pode exigir um conjunto de plataformas distintas. Em um caso SOA que estamos trabalhando atualmente, uma determinada empresa organizou a sua infraestrutura a partir de um conjunto de soluções integradas de BPMS, SOA e ESB.

Grandes fornecedores de mercado como a IBM, Oracle, TIBCO, SAP, Redhat, entre outros gigantes, possuem esquemas conceituais que nos permitem navegar neste mar de tecnologias. Deixo para os curiosos e aficionados pelo tema duas referências respectivamente da IBM e da Redhat.

Arquitetura Referência IBM

Arquitetura de Referência da IBM

Arquitetura Redhat JBOSS Enterprise Middleware

Arquitetura de Referência RedHat JBOSS

O arquiteto das nuvens

~ Marco Mendes ~ 1 comentário

A arquitetura de software existe como uma disciplina formal há quase 25 anos. Podemos destacar, ainda no início da sua base como disciplina, alguns artigos fundamentais como este: Larger Scale Systems Require Higher-Level Abstractions, da autora Mary Shaw, do ano de 1989.

Neste artigo ela escreve, de forma pioneira.

“Over the past thirty years, abstraction techniques such as high level programming languages and abstract data types have improved our ability to specify and develop software. However, the increasing size and complexity of software systems have introduced new problems that are not solved by the current techniques. These new problems involve the system-level design of software, in which the important decisions are concerned with the kinds of modules and subsystems to use and the way these modules and subsystems are organized. This level of organization, the software architecture level, requires new kinds of abstractions that capture essential properties of major subsystems and the ways they interact.”

Desde 1989, o campo da arquitetura de software evoluiu muito e diversas outras especializações surgiram tais como o Arquiteto de Soluções, o Arquiteto de Dados ou o Arquiteto de Infra-estrutura . Destaco neste post um novo membro da fauna de arquitetos, o arquiteto das nuvens ou the cloud architect.

Este novo membro da fauna de arquitetos requer competências diferenciadas a este novo mundo da computação nas nuvens, tais como:

  • Conhecer os novos modelos econômicos que podem ser alavancados por áreas de TI. Modelos de cauda longa (Big Tail), multi-inquilinos (Multitenancy), computação utilitária (Utility Computing) ou Computação Elástica (Elastic Computing) são exemplos destes modelos.
  • Conhecer e usar as diretrizes que influenciam e determinam que serviços de TI devem operar dentro da própria empresa (On-Premises) ou nas nuvens (Cloud).
  • Conhecer e saber comparar os diferentes tipos de nuvens tais como Nuvens Públicas, Nuvens Privadas ou Nuvens Híbridas.
  • Conhecer as principais soluções de mercado e fornecedores nos três pilares da Cloud Computing: Software as a Service – SAAS, Platform as a Service – PAAS e Infrastructure as a Service – IAAS.
  • Aplicar todos estes conhecimentos no desenho de soluções de software que utilizem software como serviço, plataformas como serviços e infra-estruturas virtualizadas como serviços em ambientes nas nuvens.
  • Acompanhar os projetos de ponta a ponta para garantir que atributos fundamentais como baixo acoplamento, segurança, confiabilidade e sustentabilidade (Green Computing), entre outros, estejam sendo corretamente implementados pelo time de desenvolvimento.
  • Ler mais sobre qualquer outra coisa que não seja TI. Arquitetos de nuvens devem falar a linguagem do negócio para recomendarem e sustentarem suas soluções.

Para os que querem adentrar no tema, é recomendável estudar na prática plataformas como o Database.com ou o Force, da Sales Force, o Microsoft Azure ou o Amazon AWS. Estes fornecedores, dentre outros, fornecem kits de desenvolvimento e uso gratuito de suas plataformas para provas de conceito e estudos.

“In 2000, when my partner Ben Horowitz was CEO of the first cloud computing company, Loudcloud, the cost of a customer running a basic Internet application was approximately $150,000 a month”, Marc Andreessen .

E se Benjamin Franklin fosse um arquiteto de software

~ Marco Mendes ~ Deixe um comentário

Benjamim Franklin foi um dos gênios da era moderna. Além de ser um cientista, ele também foi  jornalista, editor, autor, filantropo, abolicionista, funcionário público, diplomata, inventor e enxadrista. E se com todo este gênio, ele tivesse sido arquiteto de software?

Ele também teria nos ensinado diversas lições. A partir de um conjunto de pensamentos que resumem um pouco da filosofia de vida dele, coloco aqui lições dele projetadas no ramo da arquitetura de software.

01. Faça mais e fale menos.

“Well done is better than well said.”

Arquitetos devem fazer mais e falar menos. Isto é, arquitetos devem sair das famosas torres de marfim e dos documentos frios para a interação com as pessoas e a produção de protótipos, provas de conceitos e liberações frequentes de alfas e betas. Fazer em software significa: entregar valor. Entregar valor é código executável estável na mesa dos seus usuários.

02. Não adie riscos.

“Don’t Procrastinate.”

Arquitetos não devem adiar decisões. Isto é, eles devem identificar os fatores críticos que podem evitar o sucesso do projeto e atuar na mitigação destes riscos. Gerir riscos é uma habilidade fundamental a qualquer arquiteto.

03.  Esteja preparado.  

“By failing to prepare, you are preparing to fail.”

Arquitetos devem estar prontos para a ação. Conhecer métodos formais de arquitetura (tradicionais ou ágeis) e conhecer verdadeiramente os fundamentos da disciplina é fundamental para fazer um bom trabalho de arquitetura nos seus softwares. Acreditar que conhecer APIs Java EE ou .NET apenas é estar preparado é a primeira receita para fracassar como arquiteto.

04. Somente termina quando acaba.

“When you’re finished changing, you’re finished.”

Em média, um projeto tem 30% de seu escopo funcional mudado. Naturalmente, a arquitetura também irá mudar. Lutar contra o fato de existirem mudanças é perder tempo. Bons arquitetos entendem que  mudanças são naturais, replanejam o seu trabalho, atacam os novos riscos e renegociam os impactos desta mudança na arquitetura, seja no tempo, escopo ou financeiramente falando. Como já dizia Kent Beck: “Embrace Change”.

05. Seja um líder e movimente o seu time em direção às metas

“All mankind is divided into three classes: those that are immovable, those that are movable, and those that move.”

Arquitetos devem liderar times pragmaticamente em relação a objetivos bem estabelecidos. Bons arquitetos fogem da paralisia de análise e entregam resultados, custe o que custar. Arquitetos são seres pragmáticos.

06. Manter-se ocupado é fácil. Ser produtivo é diferente.

“Never confuse motion with action.”

Manter-se ocupado é fácil. Fazer da ocupação um trabalho produtivo é diferente. Bons arquitetos terminam o seu dia com pequenos produtos entregues. Eles se movimentam em relação aos seus alvos e não ficam ocupados em intermináveis reuniões infrutíferas ou documentos que não agregam valor tangível.

07. Errar é humano.

“Give Yourself Permission to Make Mistakes” 

Ficar na zona de conforto raramente levará um arquiteto a buscar soluções melhores para os seus software. Um excelente exemplo são as provas de conceito, que experimentam novas soluções em um projeto. Uma prova de conceito tem três resultados possíveis: sucesso, fracasso ou inconclusivo. Bons arquitetos não tem medo de fazer provas de conceito e experimentar novas soluções.

08. Seja persistente.

“Energy and persistence conquer all things.”

Arquitetar bons softwares não é trivial. Requer energia alta, trabalho duro e muita persistência. Significa negociar com gerentes e usuários. Significa liderar desenvolvedores. Significar enfrentar problemas complexos a cada dia. Significar aprender todo dia. Significa aprender a ouvir nãos e lidar (com frequência) com os seres mais arrogantes ou intransigentes que a genética do DNA humano permitiu conceber. Significa seguir em frente e não desistir.

09. Auto-conhecimento.

“There are three things extremely hard: steel, a diamond, and to know one’s self.”

Conhecer a si mesmo é fundamental para ser um arquiteto melhor e para compor o seu time. Arquitetos que reconhecem as suas forças e suas fraquezas tem a capacidade de saber o que podem fazer sozinhos, o que podem fazer em grupo e o que devem delegar.

10. Melhore sempre

“Be at war with your vices, at peace with your neighbors, and let every new year find you a better man.”

Arquitetos que acreditam que já sabem tudo estão se enganando. Como diria Benjamim Franklin, esteja em guerra com os seu vícios. Se você não consegue ouvir um estagiário, pratique a técnica de Escuta Ativa. Se o seu documento de arquitetura tem mais erros de regência verbal e uso de orações coordenadas e subordinadas do que o filho de 14 anos do seu vizinho, seja humilde para se matricular em um curso de português.  Se você não conhece a linguagem XPTO, faça um curso e frequente DOJOs aos sábados com seus amigos nerds. Se você não conhece sobre segurança ou acessibilidade Web e precisa disto em seu projeto, vá estudar sobre o assunto. Sempre haverá algo que você possa aprender na profissão de arquitetura de software.

Adaptado livremente a partir do blog de Thea Easterby – 14 Lessons From Benjamin Franklin About Getting What You Want In Life.

O princípio de Occam aplicado na escolha de soluções técnicas

~ Marco Mendes ~ Deixe um comentário

Consideremos um problema de integração ad-hoc entre duas empresas sobre um canal seguro. A empresa B precisa disponibilizar informações sobre estoques de seus produtos criados em uma aplicação ASP.NET MVC. A empresa A precisa consumir estas informações sincronamente (RPC) em uma aplicação Java EE. Os desenvolvedores nas empresas A e B conhecem suas tecnologias de desenvolvimento e o protocolo HTTP.

Um arquiteto de integração é exposto a três soluções possíveis de RPC:

1. Criar uma API sobre SOAP/HTTPS, expor os serviços da empresa em WSDL e criar objetos de dados complexos em XSD.

2.Expor a API  sobre protocolo HTTPS através dos métodos GET/POST em um mecanismo REST.

3. Criar uma comunicação CORBA sobre GIOP/IIOP a partir do uso de COM+ ou WCF em .NET e consumir o objeto remoto através de um EJB (RMI/IIOP).

A lei da parcimônia nos diz para escolher a solução 2 neste contexto, dada que é a mais simples e irá resolver o problema sem a adição de mais complexidade à solução.

Se houver algum outra variável no problema, a solução é reavaliada naturalmente. Assumi no exemplo que nenhum outra questão se faz presente para tornar a explicação mais didática.A lei da parcimônia é antiga e foi formulada por Willian of Ockham ainda no século 14. Ele descreveu o princípio que é conhecido como lâmina de Occam, que diz  que a explicação para qualquer problema deve assumir apenas as premissas estritamente necessárias à explicação do fenômeno e eliminar todas as que não causariam qualquer diferença aparente nas predições da hipótese ou teoria. Em outras palavras, este princípio recomenda assim que se escolha a teoria explicativa que implique o menor número de premissas assumidas e o menor número de entidades na solução. Na arquitetura e desenho de software, este princípio nos diz que a solução mais simples para resolver um problema deve ser escolhida, quando temos diversas soluções para resolver uma determinada questão.

São contra-exemplos deste princípio:

  • As famigeradas arquiteturas lasanhas do J2EE 1.3 e 1.4 com quase 10 camadas entre a tela  o banco de dados.
  • Objetos de transferência TO/VO iguais aos objetos de domínio (POJO/POCO).
  • Bancos de dados normalizados além da necessidade do problema.
  • Padrões de desenho artificiais.
  • Métodos/Funções com centenas de linhas de código.

Um bom exemplo da simplicidade aplicada é o método EssUP de Ivar Jacobson. Uma lâmina no contexto da essência arquitetural de um projeto é apresentada aqui para os interessados.

“We are to admit no more causes of natural things than such as are both true and sufficient to explain their appearances. Therefore, to the same natural effects we must, so far as possible, assign the same causes.”, Isaac Newton

O Débito Técnico Arquitetural

~ Marco Mendes ~ Deixe um comentário

Uma arquitetura de software executável é o conjunto de códigos executáveis que suportam os requisitos (casos de uso, estórias do usuário ou telas) mais importantes para o negócio e que afetam os elementos técnicos de um sistema em amplitude. Idealmente, a construção de uma arquitetura executável deve possuir códigos para todos os mecanismos arquiteturais identificados em uma arquitetura candidata (documento de arquitetura de software ou caderno arquitetural). Um mecanismo arquitetural é uma tática técnica importante para o desenvolvimento de uma solução de software, como por exemplo a autenticação em sistemas de home banking, a usabilidade facilitada em redes sociais ou a eficiência operacional na entrada de dados em call-centers.

O mundo real e a pressão por entregas em produção, entretanto, é implacável. Gerentes e clientes pressionam os times técnicos por prazos cada vez mais arrojados. Como mágicas e unicórnios não existem, uma técnica chamada de gestão do débito técnico arquitetural pode ajudar nesta questão.

Débito Técnico Arquitetural

Uma arquitetura de software ideal implementa n táticas arquiteturais. Uma arquitetura evolutiva, ao invés, implementa m|m < n táticas arquiteturais. Uma tática arquitetural deliberadamente ausente será adiada na primeira entrega em produção. Esta ação irá gerar dois efeitos (um positivo e um negativo).

  • O atendimento a prazos de negócio como por exemplo regulações ou pressões da área de marketing de uma empresa para lançar um novo produto;
  • Um produto que deve um atributo de qualidade não realizada por alguma tática. Por exemplo, um código com manutenibilidade reduzida ou uma aplicação Web com ausência de portabilidade entre navegadores.

Os Juros do Banco Arquitetural

O banco arquitetural cobra juros altos, proporcionais ao tamanho do sistema em termos de seus requisitos e o custo da refatoração de cada caso de uso.

Débito Arquitetural = ƒ (Número de Requisitos, Custo Médio de Refatoração Arquitetural por Requisito)

Como exemplo, se um sistema tem 70 telas e o custo de refatoração e testes para portabilidade ao navegador Chrome é de 8 horas por caso de uso, temos um débito arquitetural de 560 horas. Se o custo médio de um profissional de uma fábrica de software é de 60 reais, então podemos até quantificar o débito técnico da arquitetural em R$ 33.600 reais.

É importante lembrar que que sistemas crescem em termos de suas funcionalidades ao longo do tempo e portanto o débito aumenta à medida que o tempo aumenta. Este aumento não é linear pois quanto mais tempo decorre menor se torna o conhecimento sobre os atributos de qualidade originalmente implementados, i.e., o custo de unidade da refatoração também tende a aumentar.

Ir ou não ao Banco Arquitetural?

Se o benefício de negócio é maior que o débito técnico gerado, então o uso de uma arquitetura evolutiva pode se tornar um bom negócio para a empresa. Embora isso incomode os engenheiros de software e arquitetos mais puristas, é importante entender que um projeto de software é apenas uma engrenagem no contexto de uma empresa e que muitas vezes o débito pode ser tornar uma questão de sobrevivência empresarial.

Por exemplo, se no exemplo anterior a área de marketing estimou que um produto lançado 2 meses antes devido a ausência de suporte ao Chrome poderá gerar R$ 100.000 reais de benefícios de negócio, então a portabilidade multi-navegador poderia ser hipoteticamente adiada para uma v2.0 do produto. O lucro com a decisão poderia gerar quase R$ 70.000 reais para a empresa, descontados já o pagamento do débito.

A análise no mundo real, naturalmente, deve ser mais criteriosa e pode considerar uma análise quantitativa de riscos para incluir ao valor do débito arquitetural. A mensagem final, entretanto, é que arquiteturas evolutivas podem ser excelentes mecanismos para responder a pressões de mercado e atendimento a elementos regulatórios.