Um Guia de A a Z para tornar-se Arquiteto

Publicado em: 28 de outubro de 2008

Por Mark Bloodworth e Marc Holmes

Ser um arquiteto não quer dizer apenas pessoas "confusas" = Coach (treinar) com gráficos pouco comuns que só fazem sentido enquanto o autor está na mesma sala. Arquitetos já não podem mais acenar de forma crítica e rejeitar uma idéia por ser "inconsistente com a arquitetura prescrita". Hoje em dia, arquitetos têm muitas e diferentes responsabilidades: com o negócio, a equipe, a visão, a tecnologia e até mesmo com o mundo lá fora.

Neste artigo, Mark Blookworth e Marc Holmes oferecem um guia prático, de A a Z, sobre como ser um arquiteto. Boa sorte e que todas as suas arquiteturas sejam de "n-camadas", o que, considerando que "n" pode ser qualquer valor diferente de 1 e "camada" apenas uma metáfora de pedaços de código similar, pode dar certo...

Os arquitetos precisam explicar e fazer recomendações sobre questões técnicas aos participantes do negócio. Eles também precisam estar aptos a assessorar equipes de produção sobre como construir. Esta recomendação é a moeda de um arquiteto; se investida com sabedoria, os lucros serão boa vontade e confiança. Todos pedem conselhos ao arquiteto, porque é trabalho do arquiteto "enxergar o todo".

Veja também: Abstraction (abstração), Agile (ágil), Acrobat (acrobata), Availability (disponibilidade), Analysis (análise), Applications (aplicativos)

Todas as decisões envolvem trocas — por exemplo, incluir uma medida de segurança pode comprometer o desempenho. É tarefa do arquiteto definir a troca correta. A arquitetura pode ser um jogo de resultado zero, mas saber o que o sistema deve obter permite ao arquiteto escolher as trocas que faz dele um sucesso. Por certo, sempre que há objetivos conflitantes, fica a cargo do arquiteto explicar o problema e procurar a resolução por meio da atribuição de prioridades aos objetivos.

Veja também: Best Practice (melhor prática), Benchmarks (índices de desempenho), Building Blocks (blocos de construção)

Com tantas alternativas para implementar uma solução, os arquitetos não podem simplesmente impor às equipes de desenvolvimento a sua noção de "arquitetura". Eles, agora, são chamados para treinar as equipes de desenvolvimento. Capacidades não-técnicas são necessárias: perguntar como e por que em lugar de instruir "faça isso" e "faça aquilo". Isso é bom. Equipes de desenvolvimento que entendem os motivos da arquitetura tendem a se comprometer e, provavelmente, farão um trabalho melhor na implementação. Os arquitetos também podem começar a identificar talentos nas equipes de desenvolvimento e oferecer boas oportunidades de desenvolvimento da carreira.

Veja também: Communication (comunicação), Champion (defesa), Context (contexto), Collaboration (colaboração), C#

As relações entre os componentes que compõem uma arquitetura são de importância fundamental. As dependências são inevitáveis, mas deveriam ser tão poucas e administráveis quanto possível. Desenhe um diagrama e mapeie as dependências. Círculos, quer diretos (A depende de B e vice-versa) ou indiretos (A depende de B que depende de C que depende de A) não são uma boa coisa. Se muitas coisas dependem de D, então D precisa ser estável porque em qualquer alteração o efeito será significativo.

Veja também: Design (projeto), Development (desenvolvimento), Delivery (entrega), Domain (domínio), Documentation (documentação)

Os arquitetos precisam ser advogados das escolhas que fizeram: os outros precisam acreditar nas idéias, nos frameworks e nos valores que orientam uma arquitetura. O evangelismo refere-se a contar histórias para diferentes pessoas. Uma segmentação simples pode ser um público técnico versus comercial, mas na verdade existem muitos públicos diferentes entre esses dois pólos. A arquitetura precisa ter uma história convincente para cada um deles. Um evangelista é capaz de sintetizar e simplificar cenários complexos para o benefício do entendimento comum.

Veja também: Enterprise (empresa), Engineer (engenheiro), Enthusiast (entusiasta)

Criar a arquitetura para uma solução pode ser difícil. Criar a arquitetura para várias soluções é muito difícil — especialmente se considerarmos as pressões de prazo e a integração entre as soluções. Um framework arquitetural é uma estrutura que remove algumas das reinvenções da roda que, de outra forma, poderiam acontecer. Oferece ferramentas, métodos e um vocabulário comum para o processo de criar uma arquitetura. O framework de uma arquitetura pode ser considerado para resolver o "como" da arquitetura.

Veja também: Facts (fatos), Functionality (funcionalidade), F#, Firewall

Haverá um dia, como se costuma dizer, em que teremos de vestir o terno se quisermos negociar a sério. Controle é uma parte importante da realização de uma visão arquitetural. Independentemente do modelo de TI — centralizada, descentralizada ou federada — haverá necessidades conflitantes de igual valor. Uma boa arquitetura precisa ter condições de ceder às diferentes necessidades, mas não tanto, a ponto de perder os valores da arquitetura para o indispensável, imediato, possivelmente de curto prazo, para o negócio. Igualmente, boa governança pode oferecer uma visão positiva, tipo painel, da tecnologia do negócio. Entendimento comum é sempre uma boa coisa.

Veja também: Generative Programming (programação generativa), Generalist (generalista)

"OS ARQUITETOS PODEM SER PORTA-VOZES DAS EQUIPES TÉCNICAS E OS OUVIDOS DO NEGÓCIO PARA A INOVAÇÃO".

Compreender como ocorre a interação entre as pessoas e os sistemas que os apóiam, é fundamental para a realização de soluções bem sucedidas. A dinâmica de cada projeto e da equipe serão diferentes; as relações entre os participantes e as suas motivações podem ser exclusivas para um determinado projeto. Saber como dirigir as relações humanas é uma habilidade-chave dos bons arquitetos e líderes.

Veja também: Heterogeneous Environments (ambientes heterogêneos), Heated Debates (debates acalorados), High Performance Computing (computação de alto desempenho)

Muitos produtos podem ser vistos como um ciclo de invenção, inovação, comoditização e redundância. A invenção é cara, demorada e pode depender da sorte e de grandes avanços de pensamento. Quando chega a comoditização, acabou o jogo, e aproveitar o que já está feito talvez seja a melhor opção. Assim, de modo geral, é no espaço da inovação que as vantagens — eficiência, diferenciação competitiva, etc. — podem ser alcançadas por meio de evoluções e revoluções talvez menores mas não menos valiosas das idéias e soluções existentes. Equipes pequenas podem forçar a inovação constantemente e arriscar-se a fazer o seu nome. Grupos e organizações maiores talvez não consigam mover-se tão rapidamente, mas precisam deixar a inovação permear dos indivíduos e das equipes para desenvolver mecanismos que tirem o melhor de sua inspiração e imaginação. Os arquitetos podem ser porta-vozes das equipes técnicas e os ouvidos do negócio para a inovação.

Veja também: Integrity (integridade), Inspiration (inspiração, Infrastructure (infra-estrutura)

Quando a discussão se estabelece e uma decisão técnica precisa ser tomada, o arquiteto vai precisar aplicar o seu discernimento. A equipe confia no arquiteto para essas chamadas de discernimento e, ao exercê-las a contento, o arquiteto transmite confiança para a equipe. Para o melhor ou pior, uma série de chamadas boas ou más pode caracterizar o arquiteto: conservador ou ousado, impulsivo ou visionário, influenciável ou audaz.

Exercer o bom discernimento é vital mas, na prática, até o bom discernimento pode, algumas vezes, se revelar errado. Não tenha medo de errar: preocupe-se mais se não fizer nada.

Veja também: Java, Just In Time

O conhecimento é uma ferramenta arquitetural primordial. Por certo, conhecer os limites do seu conhecimento é uma boa coisa. Áreas sabidamente desconhecidas são perfeitas para prova de conceitos e outros exercícios para construção do conhecimento. Por outro lado, desconhecimentos desconhecidos são coisas ruins: equivalem a gremlins arquiteturais. O conhecimento da tecnologia é apenas um domínio, embora importante, sobre o qual o arquiteto precisa ter controle. O arquiteto também precisa conhecer os fatores não- técnicos que estarão em jogo, como as estruturas organizacionais, a estratégia corporativa, os processos do negócio e as metodologias de desenvolvimento.

Veja também: Kernel, Keyboard (teclado)

A liderança é qualidade vital para arquitetos e, em geral, apresenta-se de duas formas: liderança de pensamento e de equipe. Como guardião da arquitetura e dos valores que apóiam a arquitetura, o arquiteto é líder de pensamento: reavalia continuamente a visão e reapresenta a visão "mais nova e brilhante", comentando as visões conflitantes e a tecnologia emergente. Como líder da equipe, o arquiteto talvez não seja solicitado a executar as tarefas de gerenciamento de linha, mas pode ser chamado para ser um ícone para o restante da equipe oferecendo confiança, visão compenetrada, motivação e inspiração.

Veja também: Lean, Linux, Latency (latência), Load Balancing (balanceamento de carga)

Um modelo é uma representação de alguma coisa — por exemplo, um processo do negócio ou um sistema para computador. As visões de um modelo oferecem um modelo para comunicar e entender idéias sobre o problema e a solução. Diferentes visões abordam diferentes preocupações — sobrecarregar uma visão para tentar abordar várias delas levará a uma visão super complicada ou a um entendimento muito simples. Ter uma notação compartilhada para representar essas visões de um modelo pode simplificar as conversas sobre o modelo — ainda que se a notação tornar-se muito complexa, este benefício logo estará perdido.

Veja também: Management (gerenciamento), Maintainability (facilidade de manutenção), Messaging (troca de mensagens)

Camada de dados, camada da lógica do negócio, camada da interface do usuário. Trabalho feito. Bem, não exatamente. Na melhor das hipóteses, n-camadas é um termo vago e, na verdade, nada diz, a não ser apontar para a idéia de que deveria haver algum tipo de separação de preocupações entre os vários pedaços de código. Com a arquitetura orientada a serviço (SOA) e, mais recentemente, a explosão dos serviços na nuvem — como back-end (armazenamento na nuvem, por exemplo) ou front-end (como o Facebook) — descrever a arquitetura, na verdade, pode ser mais difícil do que construí-la. Somos fãs da abordagem da "placa de Petri": círculos concêntricos usualmente contêm caixas quadradas como se suspensas em geléia de agar.

Veja também: Needs (necessidades), Networks (redes), Nonfunctional Requirements (exigências não-funcionais), .NET

A orientação a objeto (OO) é um paradigma de programação que se tornou proeminente na década de 1990. Pode ser considerado como uma forma de conquistar a complexidade dividindo um grande problema ou programa em bocados digeríveis e, claro, blocos com coerência lógica. A orientação a objeto é quase sempre denominada OO e algumas vezes OOP (programação orientada a objeto), quase próximo do acrônimo que a faria parecer um erro. Para garantir proteção do acrônimo, devemos também mencionar OOAD (análise e projeto orientado a objeto). A orientação a objeto é tanto uma técnica de análise como um paradigma de programação, embora a tradução seja quase sempre necessária de um modelo de análise ou conceitual para um modelo de projeto, ou lógico — assim como existe entre o modelo do projeto e o modelo da implementação, ou físico. Um objeto — a entidade no núcleo da OO — contém comportamento e dados, e a funcionalidade de um sistema é alcançada por meio da interação dos objetos. Os objetos, instâncias de classes, expõem as suas habilidades por meio dos métodos. Existem, como era esperado, alguns conceitos e termos centrais a serem aprendidos para se ter a compreensão da OO — sendo os mais importantes: herança, polimorfismo, encapsulamento e abstração.

Veja também: Operations (operações), Object-Relational Mapping (mapeamento relacional a objeto), Operating System (sistema operacional), OLAP (Online analytic processing ou processamento analítico em tempo real)

dos quatro e os seus padrões originais de projeto; agora, existem muitos recursos e livros dedicados a padrões em muitas disciplinas. Alguns são mais forte do que outros e, provavelmente, é preciso arrancar os padrões tipo "erva-daninha" para ter um jardim arquitetural bem cuidado. Os padrões oferecem um modelo para a implementação de determinado conceito mas, também, uma linguagem comum para se discutir conceitos abstratos e complexos, sem a necessidade de recorrer a uma descrição completa, ou um diagrama — embora nós, com quase certeza, faríamos isso também.

Veja também: Principles (princípios), Platforms (plataformas), Politics (política), Performance (desempenho), Process (processo)

Em geral, qualidade é entendida como sinônimo de bom. É difícil definir e avaliar o que é bom. A qualidade deveria ser definida e possível de avaliar. Quando se fala em qualidade, queremos dizer que a solução atende às necessidades e que todas as normas aplicáveis (conforme definidas pela empresa, pelo setor, autoridade estatutária, etc.) Ao definir e especificar os índices e as normas, a solução pode ser avaliada — e, se necessário, aprimorada.

Veja também: Qualifications(qualificações, Queries (consultas), Quantification (quantificação), Quantum Computing

A arquitetura e a vida real às vezes se soltam e é aí que ocorre a diferença nos tempos entre a produção dos conceitos e a subseqüente realização da visão. Muitos obstáculos se interpõem no caminho de uma bela arquitetura: visões divergentes, mudança na estratégia do produto, necessidades táticas de curto prazo. Um mapa pode ajudar a manter a visão original, oferecendo uma visão do agora, dos momentos seguintes e dos futuros da implementação. O mapa pode oferecer ao negócio uma visão dos planos e metas das equipes de tecnologia. Além disso, também pode, algumas vezes, ajudá-lo a se lembrar o que estava tentando fazer em primeiro lugar.

Veja também: Requirements (exigências), Realization (realização)

"COMO GUARDIÃO DA ARQUITETURA E DOS VALORES QUE APÓIAM A ARQUITETURA, O ARQUITETO É LÍDER DE PENSAMENTO. COMO LÍDER DA EQUIPE, O ARQUITETO TALVEZ NÃO SEJA SOLICITADO A EXECUTAR AS TAREFAS DE GERENCIAMENTO DE LINHA, MAS PODE SER CHAMADO PARA SER UM ÍCONE PARA O RESTANTE DA EQUIPE OFERECENDO CONFIANÇA, VISÃO COMPENETRADA, MOTIVAÇÃO E INSPIRAÇÃO".

A estratégia define como alcançar as suas metas. A estratégia arquitetural deriva-se da estratégia corporativa — deve permitir à empresa alcançar as suas metas. A palavra "estratégico" deve ser usada com critério e cautela — muitos antes de você já a usaram para justificar investimentos de longo prazo caros, com benefícios mal definidos. Uma estratégia, como um bom plano militar, deve ser adaptável — caso contrário vai desmoronar quando encontrar a realidade. Quase sempre a estratégia é confundida com tática (e, às vezes, por engano, pensa-se que é uma idéia oposta à tática). A tática envolve ações específicas que, ao atingir os objetivos, representam a implementação da sua estratégia.

Veja também: Services (serviços), Software, Standards (normas), Security (segurança), Scalability (escalabilidade) ,

Como qualquer habilidade, pensar não é, de modo geral, um problema para desenvolvedores e arquitetos. Descobrir o espaço e o tempo para pensar já é um pouco mais difícil. Nestes dias de constante bombardeio de informações da blogosfera — boas, más e feias — algumas vezes pode ser difícil encontrar a inclinação para pensar por si. Tal atividade fundamental precisa de um enfoque e arquitetos devem estar preparados para conseguir o espaço, o tempo e protegê-los. Pense sobre pensar: O que é melhor para você? Viagens de trem longas? Música? Uma banheira de água quente? Pode ser difícil instalar um "quarto de banho" no escritório, mas... nunca se sabe.

Veja também: Technology (tecnologia), Transparency (transparência)

O entendimento complementa o conhecimento. Entender as pessoas, os sistemas e os processos faz uma incrível diferença no resultado de uma solução. É a antítese da premissa. Alguns tipos perversos apresentarão a premissa como compreensão — isto é, sem dúvida, uma coisa ruim e não levará à terra prometida da boa arquitetura. Perguntar é uma técnica-chave para alcançar o entendimento — usado com inteligência pode puncionar a premissa, o mito e outras forças que poderão "sabotar" um projeto.

Veja também: UML, Unix

Os valores de uma arquitetura são melhor expressos como princípios — o sistema de valor que guia a tomada de decisão, e a prática arquitetural é feita desses valores. Os princípios são, portanto, a fundação que sustenta a arquitetura. Para serem eficientes, não deve haver mais do que um punhado, em nível corporativo, os quais devem ter o apoio dos líderes de alto escalão. Um bom princípio é claro, regular, relevante, com enfoque adequado, adaptável e estável.

Veja também: Virtualization (virtualização), Visualization (visualização), Views (visões)

Boas habilidades no quadro branco são uma verdadeira arte — é fácil tornar-se aprendiz, mas adquirir o domínio é sempre mais ilusório. Tendo em mãos os fatos de nossas próprias carreiras, desconfiamos que muitas grandes idéias nunca foram implementadas simplesmente devido à má apresentação do quadro branco. No futuro, se os pioneiros da tecnologia de computação forem lembrados (você, a propósito) o monumento mais digno seria uma enorme estátua de um quadro branco em mármore branco puro, com apenas alguns rabiscos do uso acidental de um marcador permanente.

Veja também: Workflow, Wikis, Windows, Web

A XML tornou-se uma linguagem de marcação universal — fornecendo, assim, um formato não proprietário de armazenamento de dados e um meio de integrar sistemas e aplicativos. Embora tenha os seus detratores e haja linguagens de marcação rivais (como JSON e YAML), não há nada, até hoje, que possa se comparar ao alcance da XML. Embora alguns pensem que a XML é o esperanto da Web, ela não é nada mais do que a base de uma linguagem compartilhada. Pense sobre XML como quem fornece as letras e a pontuação, mas não as palavras nem a gramática. O esquema XML (XSD) oferece um meio de definir documentos XML que podem ser compartilhados e usados para validar documentos. E, enquanto há alternativas, como RelaxNG, XSD, like XML, há alcance suficientemente amplo que provavelmente será entendido por parceiros e clientes.

Veja também: XSD, XPath, XQuery, XAML, XOML

Quase sempre, grandes projetos não são projetos grandiosos. Usar bom discernimento para decidir quando construir novos recursos ou reutilizar trabalho já feito ou ignorar os recursos, tudo faz parte do jogo arquitetural. Ainda assim, continuar a construir novas coisas para o caso de serem necessárias no futuro pode ser atraente, pois "nunca se sabe". Por certo, como sabe — hoje em dia não são muitos os softwares que duram tanto tempo devido a novas técnicas, canais e até linguagens que podem ser exploradas. Se não tiver certeza, então, muito provavelmente, você não vai precisar disso (You Ain't Gonna need It - YAGNI).

Veja também: YAML, Yottabyte

Zeitgeist ou o "espírito da época" é um aspecto importante do pensamento, valores e liderança. Ampliam-se proporcionalmente à manifestação das próprias "épocas". Afinal de contas, estamos na Web 2.0. Saber como reagir ao zeitgeist garante que as etapas certas serão seguidas para responder à circunstância da mudança: "Vamos nos reinventar como o Facebook de amanhã". De modo geral, para um arquiteto, não é tanto a manifestação do pensamento novo — esses são apenas implementações — como os memes subjacentes e a sua importância no cenário da tecnologia. Todo o mundo vê "relacionamento social" onde o arquiteto vê "Web semântica".'

Veja também: Zeal (empenho), Zettabyte, Zero Day Exploit

Para concluir

Quando decidimos compilar este guia de A a Z, pensamos qual seria o desafio de construí-lo. Na verdade, as possibilidades nos inundaram e gastamos muito tempo debatendo os méritos de cada entrada.

Para nós, a lista foi uma afirmação de que a arquitetura tem muito de habilidades não-técnicas (soft skills): bom discernimento, equilíbrio e outra sabedoria, pois trata-se de compreender o amplo cenário técnico, ou as habilidades exigidas para projetar e implementar uma arquitetura.

Nós nos divertimos muito ao escrever a nossa versão deste A a Z, mas gostaríamos de receber as suas próprias alternativas. Não seríamos arquitetos se todos concordássemos com a mesma lista!

Sobre os autores

Mark Bloodworth é arquiteto evangelista da equipe Developer and Platform Evangelism na Microsoft. Antes de ingressar na Microsoft, Mark era arquiteto-chefe de soluções na BBC Worldwide, onde liderou uma equipe responsável por arquitetura e análise de sistemas. Esta função englobou estratégia técnica, arquitetura e gerenciamento de equipe. Mark tem histórico em desenvolvimento e projeto de software, especialização em integração e aplicativos de Web. A maior parte da sua carreira tem se concentrado no uso das tecnologias Microsoft, especialmente .NET, com adição de um pouco de Java para um bom equilíbrio. Mark mantém um blog no endereço remark.wordpress.com.

Marc Holmes é arquiteto evangelista da equipe Developer and Platform Evangelism da Microsoft no Reino Unido, onde especializa-se em arquitetura, projeto e prova de trabalho conceitual com grande variedade de clientes, parceiros e ISVs (fornecedores de software independente). Antes da Microsoft, Marc, recentemente, liderou uma equipe representativa de desenvolvimento como Head of Applications and Web na BBC Worldwide Ltd. Marc é autor de Expert .NET Delivery Using NAnt and CruiseControl.NET (Berkeley, CA: APress, 2005) e mantém um blog no endereço http://www.marcmywords.org.