O documento discute o papel do arquiteto de software e define arquitetura. A arquitetura é definida como a parte importante do sistema para os desenvolvedores experientes. Um bom arquiteto, chamado de Architectus Oryzus, colabora com a equipe para resolver problemas, em vez de tomar todas as decisões. A irreversibilidade é apontada como um fator que aumenta a complexidade, e arquitetos devem encontrar formas de reduzi-la nos projetos.
1. sua organização ou estrutura de componentes
importantes interagindo através de interfaces, sendo
Quem precisa de um arquiteto? - estes componentes compostos por outros
Martin Fowler componentes e interfaces sucessivamente menores”.
Passando pelo corredor um tempo atrás, vi meu
colega Dave Rice de mau humor. Minha pergunta Johnson respondeu:
sobre o que está acontecendo trouxe uma resposta “Eu era um revisor no padrão IEEE que dizia isso, e eu
violenta, “não devemos entrevistar ninguém que reclamei inutilmente que isso era uma definição falsa.
tenha o título 'arquiteto' no seu currículo”. Naquele Não existe um conceito de alto nível de um sistema.
momento, foi uma frase estranha, pois nós Clientes tem um conceito diferente dos
normalmente apresentamos Dave como um dos desenvolvedores. Clientes não se preocupam com a
nossos melhores arquitetos. estrutura dos componentes. Então, talvez a
A razão para o seu ódio a títulos é o fato de que, arquitetura é o conceito de mais alto nível que os
mesmo para os padrões da nossa indústria, desenvolvedores tem de um sistema em seu
“arquiteto” e “arquitetura” são palavras terrívelmente ambiente. Vamos esquecer os desenvolvedores que
sobregarregadas. Para muitos, o termo “arquiteto de conhecem apenas o seu pequeno pedaço. Arquitetura
software” cabe perfeitamente no personagem que é o conceito de mais alto nível dos desenvolvedores
conhecemos no fim de Matrix Reloaded. Até mesmo experientes. O que faz um componente importante?
em empresas que são contrárias a esta imagem, há Ele é importante porque os desenvolvedores mais
uma necessidade vital para a liderança técnica que um experientes dizem que é.
arquiteto como Dave desempenha. Então, uma definição melhor seria 'Na maior parte
dos projetos de software de sucesso, os
O que é arquitetura?
desenvolvedores mais experientes trabalhando
Quando eu estava avaliando o título para “Patterns of
naquele projeto tem um conhecimento compartilhado
Enterprise Application Architecture”, todos que
do design do sistema. Esse conhecimento
faziam a revisão do livro diziam que o termo
compartilhado é chamado 'arquitetura'. Esse
“arquitetura” cabia bem no título. Mas sentíamos
entendimento inclui como o sistema é dividido em
desconfortáveis ao definir a palavra. Como era me
componentes e como os componentes interagem
livro, senti que deveria tomar posição e defini-la eu
entre si através de interfaces. Estes componentes são
mesmo.
normalmente compostos de componentes menores,
Meu primeiro movimento foi evitar a complicação e mas a arquitetura inclui apenas os componentes e
apenas deixar o meu cinismo falar. Aparentemente, interfaces que são conhecidas por todos os
definimos “arquitetura” como a palavra que usamos desenvolvedores.”
quando queremos falar do design de software mas
Isso seria uma definição melhor porque ela deixa claro
queremos que ele pareça mais importante do que é.
que arquitetura é uma construção social (assim como
(Sim, você pode imaginar que para “arquiteto” é a
o software em si) porque ela não depende do
mesma coisa). Entretanto, como acontece de forma
software, mas em qual parte do software é
tão comum, de dentro do cinismo existe um pedaço
considerada importante pelo grupo como um todo.
de verdade. O entendimento veio a mim após ler um
texto de Ralph Johnson na lista de Extreme Há outro estilo de definição de arquitetura que é algo
Programming. É tão bom que vou citá-lo aqui por como “arquitetura é o conjunto de decisões de design
completo. que precisam ser feitas cedo em um projeto”. Talvez
essa ficasse melhor definida como sendo arquitetura é
Uma mensagem anterior dizia:
o conjunto de decisões que você gostaria de ter
“O RUP, vindo da definição do IEEE, define arquitetura tomado cedo em um projeto, mas que você não tem
como “o conceito de mais alto nível de um sistema em necessariamente condições de acertá-las no início de
seu ambiente. A arquitetura de um sistema de qualquer forma.
software (ao um momento específico no tempo) é a
2. Assim, por esta segunda definição, a linguagem de códigos parecidos. Na tarte, o arquiteto participa de
programação selecionada seria parte da arquitetura sessões de requerimentos, ajudando a explicar ao
da maior parte dos projetos. Pela primeira, não seria. pessoa dos requisitos as consequências técnicas das
duas ideias em termos não técnicos – como custos de
Se algo é parte da arquitetura é completamente
desenvolvimento.
baseado no que os desenvolvedores acham que é
importante. Pessoas que constroem “aplicações A atividade mais importante do Architetus Oryzus é
enterprise” tendem a pensar que persistência é melhorar a equipe de desenvolvimento para que eles
crucial. Quando eles começam a preparar suas possam resolver problemas mais complexos. Melhorar
arquiteturas, eles começam com 3 camadas. Eles vão a habilidade da equipe dá ao arquiteto muito mais
mencionar “e nós usamos Oracle para o nosso banco opções do que ser o único tomador de decisões e
de dados e temos a nossa própria camada de correr o risco de ser um gargalo para a equipe. Isso
persistência para mapear os nossos objetos para ele”. leva para a regra de que a importância de um
Mas uma aplicação de controle de imagens para arquiteto é inversamente proporcional ao número de
médicos pode incluir o Oracle sem que ele seja decisões que ele ou ela fazem.
considerado parte da arquitetura. Isso porque a maior
parte da aplicação é analisar imagens, não gravá-las. Em uma reunião recente na ThoughtWorks, alguns
Receber e gravar imagens é feito por uma pequena colegas e eu estávamos discutindo sobre o problema
parte da aplicação e a maior parte dos dos arquitetos. Achei interessante que nós
rapidamente chegamos ao consenso sobre a definição
desenvolvedores ignoram isso.
do Architectus Oryzus mas não conseguíamos
Então, isso faz com que seja difícil dizer as pessoas encontrar um nome. Mike Two veio com o melhor
como descrever sua arquitetura. “Nos diga o que é nome que eu já ouvi: guia, como em montanhismo.
importante”. Arquitetura é sobre a parte importante. Um guia é um membro da equipe que tem mais
Seja lá o que isso for. experiência e que ensina os outros membros a
resolverem seus problemas, mas sempre está lá
O Papel do Arquiteto quando alguma coisa sai do controle.
Então se arquitetura é a parte importante, então o
arquiteto é a pessoa (ou pessoas) que se preocupam Largando a arquitetura
com a parte importante. E aqui nós chegamos na Eu adoro escrever um título chamativo, e o melhor,
essência da diferença entre o arquiteto de Matrix como esse mesmo, tem um significado importante
Reloaded e o arquiteto que Dave Rice exeplifica. que não é imediatamente óbvio. Lembre-se da
segunda definição de Johnson: “Arquitetura é as
Arquitectus Reloadus é a pessoa que faz todas as decisões que você gostaria de ter feito cedo em um
decisões importantes. O arquiteto faz isso porque projeto”. Por que as pessoas sentem a necessidade de
uma mente única é necessária para manter a ter algumas coisas cedo no projeto? A resposta, claro,
integridade conceitual do sistema e talvez porque o é porque eles percebem essas coisas como difíceis de
arquiteto não acha que os membros da equipe são serem mudadas. Então você pode acabar por definir
suficientemente bons no trabalho para tomar aquelas arquitetura como “coisas que as pessoas percebem
decisões. Frequentemente, tais decisões precisam ser como difíceis de serem mudadas”.
feito no início para que todos tenham um plano a
seguir. É comummente entendido que se você está
construindo uma aplicação “enterprise”, você precisa
Architectus Oryzus é um animal diferente. Este tipo de acertar no banco de dados desde o início porque é
arquiteto deve estar sempre a par do que está difícil de mudar o banco de dados – especialmente
acontecendo no projeto, procurando por problemas depois que o projeto vai ao ar. Um dos nossos
importantes e resolvendo-os antes que eles tornem- projetos, o DBA Pramod Sadalage, desenvolveu um
se um problema sério. Quando eu vejo um arquiteto sistema que nos permite alterar o schema do banco
como esse, a parte mais notável do trabalho é de dados de forma simples. Ao fazer isso, ele fez com
colaboração intensa. Na manhã, o arquiteto programa que o schema do banco não era mais arquitetural. I
com um desenvolvedor, procurando encontrar
3. vejo isso como uma coisa boa porque ele nos deixa
mais livres para lidar com mudanças.
Em uma apresentação fascinante na conferência
XP2002, Enrico Zaninotto, um econonista, analisou o
pensamento por trás das ideias ágeis na manufatura e
desenvolvimento de software. Um aspecto que eu
achei particularmente interessante foi seu comentário
de que a irreversibilidade era um dos maiores
motores da complexidade. Ele via métodos ágeis, em
manufatura e desenvolvimento de software, como
uma mudança que procura conter a complexidade ao
reduzir a irreversibilidade – ao contrário de atacar as
outras fontes de complexidade. Eu acredito que que
um dos trabalhos mais importantes de um arquiteto é
encontrar meios de remover a irreversibilidade nos
designs de software.
Segue um e-mail de Johnson em resposta a um e-mail
que o enviei:
“Uma da diferenças entre a arquitetura de construção
civil e de software é que várias decisões de uma
construção são difíceis de serem mudadas. É difícil
voltar e alterar o seu porão, mesmo que seja possível.
Não há uma razão teórica que diga que alguma coisa é
difícil de ser mudada em software. Se você pega um
aspecto do software você pode então fazê-lo fácil de
ser mudado, mas nós não sabemos como fazer tudo
fácil de mudar. Fazer algo fácil de mudar faz com que
o sistema seja mais complexo e fazer tudo fácil de
mudar faz todo o sistema muito complexo.
Complexidade é o que faz software ser difícil de
mudar. Isso e duplicação.
Minha reserva quanto a programação orientada a
aspectos é que nós já vemos técnicas relativamente
boas para separar os aspectos dos programas e nós
não as usamos. Eu não acho que o problema real vai
ser resolvido por melhores técnicas na separação de
aspectos. Nós não sabemos o quais aspectos devem
ser separados e não sabemos quando é válido separá-
los o não.
Software não é limitado por física como construções
são. Ele é limitado pela imaginação, design,
organização. Ele é limitado pelas propriedades das
pessoas, não pelo mundo. “Nós encontramos o
inimigo, e ele somos nós mesmos”.