Tendências de Arquitetura de Software para 2014

2014 é o primeiro ano onde o número de dispositivos mobile irá ultrapassar o número de dispositivos tradicionais (desktops), em análise recente realizada pelo Gartner Group. Esta mudança tem sido impulsionada por fatores econômicos como a redução dos preços de celulares e tables e também por aspectos culturais como o Bring Your Own Device (BYOD), Bring Your Own Appliance (BYOA) e a Internet das Coisas.

Para quem trabalha com arquitetura, estas e outras novidades trazem novos desafios para os arquitetos. Destaco alguns destes desafios em 5 tendências de arquitetura de software.

  1. Arquiteturas Móveis Corporativas

Muitos técnicos, ao pensar em aplicações móveis, pensam que o problema está apenas localizado no lado cliente, nas aplicações que rodam Android e iOS. Em verdade, a maioria das aplicações móveis faz comunicações com servidores e portanto é crítico e complexo a correta montagem arquitetural da camada servidora para lidar com aspectos como a gerência de estado offline da aplicação, sincronização de dados cliente e dados do servidor, picos de escalabilidade e renderização em múltiplos dispositivos. Este tipo de arquétipo tem sido chamado de MADM (Mobile Application Development Platform) e é um tema cada vez mais presente na realidade das grandes empresas.

2. HTML5 como linguagem multi-dispositivo

O HTML 5 ganha força e tende a se tornar uma linguagem padrão para a renderização Web e também para a renderização iOS,  Android e Windows Phone. Esta tendência, hoje implementada por diversos frameworks Web/Mobile de mercado, tem suas motivações no alto custo da geração de aplicações nativas em diversos dispositivos e uma ausência de dominância clara do mercado de dispositivos móveis por um único fornecedor.

3. A chegada dos “Arquitetos das Nuvens

A virtualização já e um fato estabelecido na indústria de TI Brasileira e a tendência da computação nas nuvens ganha força a cada dia. Compreender, escolher e arquitetar os diversos tipos de plataformas de nuvens tem se tornado um desafio formidável. Exemplos incluem o IAAS, PAAS, SAAS, DAAS, NAAS, XAAS, nuvens públicas, nuvens privadas, nuvens híbridas, nuvens pessoais, entre outros sabores de nuvens.

A necessidade de profissionais que consigam pensar apropriadamente o uso da computação nas nuvens é cada vez mais requisitado nas empresas de médio e grande porte do Brasil.

4. Arquiteturas Sensíveis ao Contexto

A Internet das Coisas liga pessoas, coisas, informações e lugares em um modelo único de valor aos seres humanos. Um exemplo futurístico pode ser visto no filme Minority Report (no ano 2053). Exemplos Reais do seu dia a dia em 2014 podem ser visto no uso do Waze para vencer o trânsito caótico das cidades, nas plataformas inteligentes da Akamai para otimizar o tráfego de dados sobre os principais backbones da Internet ou mesmo nos Smart Grids em modernas redes de distribuição de energia elétrica.

As arquiteturas sensíveis ao contexto, que podem ser observadas nos níveis mais avançados do modelo OSIMM (Open Group Service Integration Maturity Model), são arquiteturas que ligam hardware, dados e tecnologias através de conceitos avançados como iBPMS, SOA 2.0, BRMS, CEP e Analytics.

5. A proliferação de tecnologias para construir aplicações corporativas

De 1997 a 2010, o mercado de TI esteve relativamente fixado nas linguagens Java e C#, com alguns grupos de TI trabalhando em linguagens dinâmicas como PHP, Ruby e similares.

Nesta década, temos visto uma proliferação de tecnologias, como por exemplo Ruby on Rails, Sinatra, Node.JS, F#, Scala, Objective C, Erlang, Java para Android, entre outras. É uma nova era da diversidade tecnológica, onde os desenvolvedores ganham liberdade para escolher as tecnologias mais apropriadas à realidade da sua empresa.

Plataformas Arquiteturais

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 princípio de Occam aplicado na escolha de soluções técnicas

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

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 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.