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.

Um 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 Redhat JBOSS Enterprise Middleware

Uma técnica para auxílio neste processo é fornecida por uma ferramenta da psicologiachamada de Janela de Johari que também usada em alguns círculos de engenharia de requisitos.

Adapto este conceito para o contexto de arquitetura de software, exibido na figura abaixo.

A figura mostra nem todo requisito é conhecido pelo nosso time e pelos nossos usuários e este desconhecimento (nosso, dos usuários ou de ambos) é fonte de muitos problemas.

Vamos contextualizar o conceito em um exemplo didático de um sistema de Internet Banking. É natural (para qualquer arquiteto e para os usuários chave de um Banco de Crédito) que aspectos de segurança devem afetar a arquitetura executável do produto sendo criado. Portanto, aspectos de autenticação, autorização e transporte seguro estariam no quadrante Q1, que é o dos requisitos arquiteturais óbvios. Até agora não temos nenhum problema.

Vamos considerar agora alguns requisitos de qualidade interna como a manutenibilidade ou a testabilidade, que são normalmente conhecidos pelo nosso time. Normalmente aspectos de qualidade interna não são percebidos diretamente pelos usuários chave, o que os coloca no quadrante Q4. Portanto, arquitetos devem tomar cautela extrema com estes requisitos pois eles não são normalmente percebidos pelos usuários e portanto não valorizados. A consequência é que eles podem causar aos usuários a sensação de baixa produtividade na execução de código pelo time de desenvolvimento. Ainda pior, eles podem encarecer o seu projeto sem percepção de valor similar para os seus usuários.

Vamos agora considerar alguma norma obscura do Banco Central que lide com algum aspecto regulatório. Se a maturidade dos usuários envolvidos no projeto e da equipe de arquitetura for baixa, este requisito regulatório, que pode afetar a arquitetura, estaria colocado no quadrante Q3. A lição aqui é óbvia. Os usuários normalmente não conhecem todos os requisitos e portanto devemos buscar requisitos que podem afetar a arquitetura em outras fontes de informação.

Finalmente, vamos lidar os requisitos mais perigosos, que são elementos óbvios para os usuários mas não óbvios para o time. Por exemplo, o usuário pode assumir que a portabilidade entre navegadores para dispositivos móveis é dada. O time, por sua vez, pode nem ter considerado esta possibilidade. Tipicamente estes requisitos do quadrante Q2 são fontes de desgaste durante o projeto e envolvem retrabalho para o time pois afinal eles são “óbvios” para os usuários.

Em cenários ideais gostaríamos de mover todos os requisitos para o quadrante 01, mas o fato é que sempre haverá requisitos nos quadrantes Q2, Q3 e Q4 também. Naturalmente a aplicação de métodos arquiteturais de coleta de requisitos reduzirá a probabilidade que isto aconteça. Algumas dicas rápidas para isso incluem:

• Realizar reuniões e oficinas de trabalho para mover os requisitos do quadrante Q2 para o quadrante Q1. Técnicas de leitura ambiental também são úteis neste contexto.
• Buscar outras fontes de informação além do ambiente e informações fornecidos pelos próprios usuários podem mover alguns requisitos do quadrante Q3 para o quadrante Q1.
• Educar usuários sobre os requisitos que eles não conhecem pode ajudar a levar requisitos do quadrante Q4 para Q1. Em outras situações, talvez devamos remover alguns requisitos de Q4 do escopo do nosso projeto.

Pensamento do dia: “O combinado não é caro”, Anônimo

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.

Transcrevo estes temas aqui:

• Arquitetura e Colaboração: Arquitetura como um catalisador para a colaboração efetiva entre as fronteiras geográficas, culturais e técnicas.
• Técnicas de Facilitação Arquitetural: Estudos de caso da aplicação de técnicas específicas para o estabelecimento de requisitos, definição, avaliação e documentação de arquitetura.
• Sistemas de Larga Escala: O uso e evolução da engenharia de software centrada em arquitetura para lidar com sistemas de grande complexidade técnica.
• Habilidades do arquiteto: O papel do arquiteto de software e habilidades necessárias para realizar um trabalho eficaz em projetos.
• Enterprise Architecture: Arquitetura no contexto da visão de negócio e estratégia de uma organização.
• Arquitetura e Métodos Ágeis: O papel da arquitetura de software em projetos de desenvolvimento ágil. Curiosamente, este tema foi marcado também como tendência no recente radar técnico da empresa Thought Works (Tech Radar 2012).
• Evolução e extensibilidade: A escolha de padrões de arquitetura ou de estilos arquiteturais que permitem a evolução e manutenção de software.
• Certificação e Cultura: O desenvolvimento, certificação e evolução do papel do arquiteto de software dentro das organizações.
• Arquitetura e Processo: Considerações de arquitetura dentro dos processos de desenvolvimento nas organizações.

A mensagem é clara. Se você é um arquiteto de software  (ou quer ser um), não é suficiente pensar apenas nos detalhes cabeludos das tecnologias PHP, Java ou .NET. É preciso de uma visão mais ampla do significado de arquitetura e do ser um arquiteto.

Para saber mais sobre o SATURN, basta seguir este link.

The wisest mind has something yet to learn. —George Santayana

Jim Collins, renomado autor do excelente livro Good To Great, nos apresenta uma interessante metáfora sobre onde devemos focar a nossa carreira. Para isso, ele fornece dois estereótipos de profissionais.

Raposas são os profissionais que não gostam do que fazem, ou que não são talentosos no que fazem ou que fazem coisas que não lhe dão retorno (inclusive financeiro). Porcos-espinhos fazem apenas uma única coisa, mas o fazem muito bem.

A metáfora não é sobre generalistas versus especialistas, mas sobre o que determina o sucesso da nossa carreira, que é a confluência de três fatores que criam o porco-espinho profissional.

A busca pelo porco-espinho é encontrar algo dentro dos nossos interesses que adoramos fazer, que fazemos muito, mas muito bem, e que pode trazer retornos financeiros interessantes. Naturalmente, a reflexão pode nos levar à conclusão que estamos vivendo a profissão errada por diversos motivos. As vezes, é necessário apenas uma mudança dentro da nossa profissão. Em outras vezes, é necessário apenas buscar um ambiente que nos valorize enquanto profissionais. Outras vezes, e sejamos francos, devemos reconhecer que simplesmente não somos talentosos no que estamos fazendo.

Dentro da confluência dos três círculos, talvez o mais difícil seja achar aquilo em que você é excepcionalmente bom. Não basta ser bom ou muito bom. É preciso ser mais. Como diz Jim Collins, aquilo que você é o melhor no mundo.

Um bom exemplo deste processo é como algumas universidades e institutos de pesquisa selecionam seus estudantes, baseado no conceito do percentil 99. Em outras palavras, se você for um estudante e quiser entrar em uma universidade como MIT ou Stanford em um programa de pós-graduação, você precisa estar no 1% dos candidatos mais bem sucedidos nos testes para ser aceito.

De volta ao Brasil, e aos nosso empregos, é necessário fornecer tempo para a reflexão e à prática chamada por Stephen Covey de “afinar o instrumento”, que consiste em buscar as pequenas metas semanais que nos permitem que nos tornemos cada vez melhores nas nossas profissões e nas nossas vidas.

Pensamento do dia: Se você é um em um milhão na China, existem mil caras iguais a você.

As a general rule, the most successful man in life is the man who has the best information, Benjamim Disraeli

Ter acesso à informação de qualidade é um grande acelerador para o nosso dia a dia de TI, seja no mercado ou nas universidades. Compilo aqui excelentes bases de dados com artigos científicos sobre os mais variados temas de TI.

http://dl.acm.org

http://ieeexplore.ieee.org

http://www.springerlink.com/

http://onlinelibrary.wiley.com/

http://www.elsevier.com

São centenas de milhares de artigos à disposição. O acesso aos resumos (abstracts) de todas estes artigos é gratuito. E para quem está na Internet através de um IP das boas universidades Brasil afora, o acesso ao conteúdo de todos estes artigos é… gratuito!

Topologia Ponto a Ponto

A este respeito, publiquei há cerca de três anos um artigo na Java Magazine sobre estratégias de integração em aplicações Java EE. Apesar dos exemplos contextualizados para Java, o artigo é útil para desenvolvedores .NET e de outras tecnologias que estejam vivendo problemas de integração.

Discutimos no nosso artigo os seguintes tópicos:

• Estilos de integração (Transferência de arquivos, RPC, fila de mensagens e banco de dados compartilhado)
• Níveis de integração (Dados, API, Processos de Negócio e Apresentação)
• Topologia (Ponto a ponto; Hub and Spoke)
• Exemplos de tecnologias de integração em Java
• Padrões EAI, documentados originalmente por Gregor Hohpe no site EAIPatterns.

Para os interessados no problema da integração de aplicações, é um começo para organizar as ideias e praticar o racional arquitetural.

O artigo completo em formato PDF pode ser baixado aqui.

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

A fauna de arquitetos

Este novo membro da fauna 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 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.

Para uma fundamentação mais conceitual, recomendo a leitura de livros escritos na ótica de formação do conhecimento do arquiteto das nuvens. Seguem exemplos de livros nesta linha.

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

É fácil reconhecer um bom Scrum Master em um projeto ágil saudável.

Evidências da sua boa atuação incluem:

• Ele está a serviço do seu time. A sua missão é limpar os impedimentos alheios, pela manhã, tarde ou noite, custe o que custar.
• Ele assume responsabilidades. Ele sabe que ele é o responsável pelo bom andamento do sprint e pelo cumprimento do escopo nos prazos. Ele não delega os problemas para terceiros nem culpa ninguém por problemas externos.
• Ele sabe ouvir críticas do seu time. Ele também sabe que não é perfeito e sabe que precisa do feedback da sua equipe para ser um líder melhor.

Também é fácil reconhecer o Scrum Master Bizarro, versão feita de anti-matéria do planeta Bizarro. Vou chamá-lo carinhosamente de Screw Master. Infelizmente, alguns destes seres habitam as terras Brasileiras.

Evidências da sua presença nefasta incluem:

• Ele insiste no paradigma comando e controle, também conhecido como cenoura e chicote, tão comum ao modelo taylorista de gerir recursos fabris. 
• Ele não assume responsabilidades. Ele é mais esguio que um porco ensebado quando os problemas lhe são apresentados. “É culpa do retardado do analista”, “É culpa do maldito desenvolvedor”, “É culpa da idiota do testador”.
• Ele não é respeitado pelo seu time. Sintoma primeiro e último de um “chefe” que não é líder.

Se você encontrar um bizarro no comando do seu projeto, recomendo exorcizá-lo com a teoria de liderança servidora do Stephen Covey. Se nem isso adiantar, coloque-o em um vórtex multidimenstional e mande-o para o planeta bizarro antes que ele screw o seu projeto.

O esqueleto andante é um conceito que permite que a funcionalidade e a arquitetura evoluam simultaneamente. Ele acomoda os principais componentes arquiteturais e é uma excelente técnica de redução de riscos em projetos complexos.

A fase de elaboração do RUP é um exemplo interessante da produção de esqueletos andantes, que reduzem os riscos e acomodam cenários de casos de uso críticos e complexos. Em métosos ágeis como o DAD (Disciplined Agile Delivery) também vemos este tipo de técnica.

Neste tipo de técnica, é fundamental uma boa gestão de configuração. O esqueleto andante é um código evolutivo, e não descartável. A gestão de linhas de base e mecanismos de testes de unidade e  integração contínua garante que o esqueleto possa acomodar  cartilagens, tendões, músculos, nervos e peles à medida que mais e mais código complexo seja adicionado ao sistema.

Um exemplo real

Tivemos a oportunidade de acompanhar um projeto, em nosso ambiente de trabalho, recentemente colocado em produção e que usou esta técnica.  A arquitetura candidata rapidamente foi evoluída para código executável que incorporou os principais componentes arquiteturais (tecnologias Microsoft, tecnologias Java, ambientes distribuídos, elemento de tempo real, BRMS, governança e elementos avançados de monitoração).

Neste projeto em particular, dois arquitetos e um desenvolvedor trabalharam em paralelo na criação do esqueleto. A partir do estabelecimento de linhas de bases periódicas que acomodaram cenários de uso reais, os componentes arquiteturais fim a fim foram enlaçados. Em cada rodada, mais e mais requisitos (arquiteturais) eram acomodados, dando forma ao esqueleto.

Após algumas semanas com esta sistemática, o esqueleto tornou-se robusto e foi autorizado para produção. Pudemos observar que uma comunicação contínua entre o time de negócio e o time de arquitetura foi fundamental para o sucesso desta técnica. O esqueleto deve ser mostrado, testado, experimentado. É apenas isso que permite a sua evolução. No fim, pudemos ver o valor da arquitetura em termos concretos.

Neste caso, pudemos destacar também o valor dos processos ágeis. Ao promover comunicação e criar um ambiente de colaboração para suportar a experimentação do esqueleto, o mesmo foi fundamental para suportar uma evolução contínua dos requisitos e da arquitetura.